Re: ENB: urls and pictures in the body pane

[john lunzer]

Offray's Grafoscopio has some kind of mind map type view mode which he has used 
for presentations which displays images with texts. Initially just the headers 
are visible but he can expand the "node" and the body will show text /images. 
Anyway it's not the same as what you're doing here but it makes me beleive 
allowing images in a node body directly would be useful for presenting content.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Sat, Feb 4, 2017 at 11:17 AM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

>
> > Imo, images in the body pane are an essential ingredient for
> > emulating pyzo, org-mode or Jupyter cells. They are too important,
> > and way too cool, to forego.
>
> Not sure about pyzo and org-mode, but does Jupyter show images in text
> that's being edited?  I think it just renders markdown when it's not
> being edited, and shows image outputs in a split view.
>

​Yeah, dragging other editors into the discussion seems kinda irrelevant.

But I do think that images in the body editor could save a lot of real
estate during demos, for instance. I'm pretty sure that we will enjoy
having this feature. And why turn our backs on a really cool feature?

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Sat, Feb 4, 2017 at 11:33 AM, Edward K. Ream  wrote:

​> ​
For example, images are referenced indirectly *by the name attribute*
[emphasis mine] of a QTextImageFormat object.

​A longshot? It may be possible to use the name attribute to avoid uA's
altogether.  That would be sweet.

More likely, the code will need uA's at first, to start everything off.
Thereafter, it can use names to avoid confusing QTextDocument when
switching nodes.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Saturday, February 4, 2017 at 10:47:47 AM UTC-6, Terry Brown wrote:

Nonetheless, I don't think we should insert weird unicode chars into 
> peoples files, and I'm not sure it serves any purpose, seeing the char. 
> by itself carries no info.  The file should only every contain the 
> markup ( or ![alt text](url) or whatever). 
>

Hmm. Let's put this question on the back burner until a prototype is 
working. But I do have a few comments:

1. There is nothing at all "weird" about unicode code point U+FFFC (OBJECT 
REPLACEMENT CHARACTER). It's perfectly valid unicode and QTextEdit seems to 
use it appropriately.

2. Yes, Leo's atFile write code could strip it. However, recent researches 
(see below) indicate that it will turn out to be a useful placeholder.

3. If we use explicit markup, then somehow that markup must be 
hidden/unhidden. But if we simply insert images, then (eventually) 
everything will "just work" (tm).

*Recent Researches*

QTextDocument  seems to work as 
expected. From QTextDocument.resource() 
: 

Q
Returns data of the specified type from the resource with the given name.

This function is called by the rich text engine to request data that isn't 
directly stored by QTextDocument, but still associated with it. For 
example, images are referenced indirectly *by the name attribute* [emphasis 
mine] of a QTextImageFormat object.

Resources are cached internally in the document. If a resource can not be 
found in the cache, loadResource is called to try to load the resource. 
loadResource should then use addResource to add the resource to the cache.
Q

So Leo must refresh the resource caches when switching nodes, using uA's. 
That will probably be done in the tree.select logic just before calling 
setAllText, the call that triggers the colorizer.

Imo, this is an experiment well worth doing. We can debate about whether to 
add placeholder unicode characters later, but I see no reason not to do 
so.  After all, the user *did* insert a picture.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 08:42:08 -0800 (PST)
"Edward K. Ream"  wrote:

> Imo, images in the body pane are an essential ingredient for
> emulating pyzo, org-mode or Jupyter cells. They are too important,
> and way too cool, to forego.

Not sure about pyzo and org-mode, but does Jupyter show images in text
that's being edited?  I think it just renders markdown when it's not
being edited, and shows image outputs in a split view.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 04:46:00 -0800 (PST)
"Edward K. Ream"  wrote:

> On Saturday, February 4, 2017 at 6:37:11 AM UTC-6, Edward K. Ream
> wrote: 

> I should emphasize that Leo reads and writes picture characters
> without problem, because *picture characters are normal unicode
> characters*:
> 
> - Picture characters will not harm scripts provided they are in
> comments.

Nonetheless, I don't think we should insert weird unicode chars into
peoples files, and I'm not sure it serves any purpose, seeing the char.
by itself carries no info.  The file should only every contain the
markup ( or ![alt text](url) or whatever).

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Saturday, February 4, 2017 at 10:32:16 AM UTC-6, Terry Brown wrote:

personally I don't  feel the need for images in a text editor, viewrendered 
> is fine for me (or at least will be, when viewrendered 4 is released ;-)
>

Imo, images in the body pane are an essential ingredient for emulating 
pyzo, org-mode or Jupyter cells. They are too important, and way too cool, 
to forego.

Don't forget the wikiview plugin unhides text when the cursor moves 
> through it.


A timely comment. As you say, it's a much lighter approach than using the 
colorizer.

Instead of deprecating wikiview, it should be moved into Leo's core, with 
suitably renamed commands.

So at present I plan no further changes to the colorizer. I'll put the 
color branch on hold.  Instead, I'll create an image branch for further 
experiments.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

['Terry Brown' via leo-editor]

On Sat, 4 Feb 2017 01:21:26 -0800 (PST)
"Edward K. Ream"  wrote:

> The colorizer will replace the wikiview plugin. Issue #388 is moot,
> and will be closed today. The wikiview plugin is deprecated,
> effective immediately.

In general I think this analysis is good, although personally I don't
feel the need for images in a text editor, viewrendered is fine for me
(or at least will be, when viewrendered 4 is released ;-)

Don't forget the wikiview plugin unhides text when the cursor moves
through it.  I guess a command on a separate key binding would do
instead, although I find the current behavior quite smooth.
wikiview only hides things on node selection, the colorizer does it
more often, which might make "unhide on cursor contact" tricky, if it
immediately gets hidden again by the colorizer.  wikiview doesn't
re-hide until node deselection and reselection.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Saturday, February 4, 2017 at 3:21:26 AM UTC-6, Edward K. Ream wrote:

Hiding  tags will use the same machinery as hiding parts of urls. But 
> full support for pictures will involve numerous complications.
>

*tl;dr:* No plan survives contact with the enemy. But the battle is not 
lost. 


*Using explicit  elements seems dubious*
The immediate problem is that there appears to be no way to update a text 
line during colorizing.  That is, there is no methods on QDocument or 
QTextBlock that will update the present block. Blocks look like they are 
read-only. Sure, it would be possible to call body.widget.setAllText in the 
colorizer, but that seems extreme.

*Pasting images directly into QTextEdit is easy*

I found an excellent resource here 
on stack overflow.  The 
following code works:

from leo.core.leoQt import QtGui
body = c.frame.body
table = (
'application-x-leo-outline.png',
'LeoDoc.ico',
)
d = g.app.permanentScriptDict
images = d.get('images', [])
for image in table:
path = g.os_path_finalize_join(g.app.loadDir, '..', 'Icons', image)
assert g.os_path_exists(path), repr(path)
image = QtGui.QImage(path)
images.append(image)
body.wrapper.setInsertPoint(len(p.b))
cursor = body.widget.textCursor()
cursor.insertImage(image)
for i, ch in enumerate(p.b):
if ord(ch) > 128: print('new', i, ord(ch))
d ['images'] = images
#
#

*Notes*

1. The four image characters at the end were preserved across invocations 
of Leo, but they aren't visible on reload.

2. The script saves references to images in g.app.permanentScriptDict, so 
once images are visible they *stay* visible.

*A problem*

I kinda expected this problem. If I run *another *version of this script, 
with *different* images, then images in newly-selected nodes correspond to 
the last *created *images, not necessarily the desired images.

My mental model (possibly inaccurate) says that the QDocument for the 
widget associates image N with image character N.  A possible solution 
would be to switch QDocuments when switching nodes.  Another would be to 
use uA's to give QDocument some guidance. This would be more localized, but 
I have no idea how it would work.

*The way forward*

Inserting images directly into Leo's body text is the simplest thing that 
could possibly work from the user's point of view.  Indeed, the 
stack-overflow page has a discussion of using canInsertFromMimeData and 
insertFromMimeData functions. These are prerequisites for cutting/pasting 
images.

Inserting images directly into Leo's body text requires no changes at all 
to the colorizer. That's a good thing, because having the colorizer change 
text seems fraught with danger.

The big question is whether Leo can help QDocument show the correct image 
when switching node.  If the answer is yes, then Leo will use uA's to make 
images persistent when Leo reloads a .leo file.  I am going to do 
everything I can to make this strategy successful. It's worth any amount of 
work.

Edward

P. S. The colorizer will still hide UNLs and URLs as previously discussed.

EKR

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Colorizer errors

[Edward K. Ream]

On Fri, Feb 3, 2017 at 9:37 AM, Largo84  wrote:


>   File "D:\Synced\github repos\leo\leo\core\leoColorizer.py", line 1923,
> in languageTag
> name = name.replace(pattern, s)
> AttributeError: 'NoneType' object has no attribute 'replace'
>

​Thanks for this report. Fixed in master at c049bf0c71. Also fixed in the
color branch.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Saturday, February 4, 2017 at 6:37:11 AM UTC-6, Edward K. Ream wrote:
 

> *New summary*
>
> Support for live UNLs is huge.
>
> On balance, the good news about  far outweighs the bad. The 
> simplifications are global. No need for uA's or anything else. The 
> complications strictly limited to the colorizer.
>

I should emphasize that Leo reads and writes picture characters without 
problem, because *picture characters are normal unicode characters*:

- Picture characters will not harm scripts provided they are in comments.

- Unicode-aware programs (including legacy Leo) will show those characters like 
this .

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: ENB: urls and pictures in the body pane

[Edward K. Ream]

On Saturday, February 4, 2017 at 3:21:26 AM UTC-6, Edward K. Ream wrote:

*> Summary*

> ...The colorizer will replace the wikiview plugin.

Still true, but the colorizer must handle *all* of what wikiview does, 
including a variant of Leo's UNLs:

file://#some-->headlines-->mynode

and links such as:

`Python `_

Live UNLs are alternative to clones! Live, good looking, links should also 
be part of Leo's core.

> Hiding  tags will use the same machinery as hiding parts of urls. 
But full support for pictures will involve numerous complications.

There is good news and bad news ;-)

The *good news* is that Leo can handle picture tags easily, without knowing 
how Qt associates *different *images with multiple picture characters, all 
of which are (apparently) *exactly the same character*.

When the colorizer sees an  element, the colorizer will *always* do 
the following:

1. Delete all the following picture character, if it exists.

2. Insert a *new* picture character by calling:

widget.insertHtml('' % path_to_picture)

The *bad news* is that inserting/deleting picture characters could (will) 
trigger another call to QSyntaxHighlighter.highlightBlock. The colorizer 
will have to futz with states so as not to loop.  It should be doable, but 
it's like to be tricky.

*New summary*

Support for live UNLs is huge.

On balance, the good news about  far outweighs the bad. The 
simplifications are global. No need for uA's or anything else. The 
complications strictly limited to the colorizer.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

ENB: urls and pictures in the body pane

[Edward K. Ream]

This is an Engineering Notebook post discussing work to be done in the 
color branch. Feel free to ignore unless you are one of Leo's devs.

*tl;dr:* Read the summary.

This post affects three issues:

#388: wikiview.py plugin problem with new colorizing code 


#372: Support something like emacs electric url's 


#396: Show images in Leo's body pane 


*Hiding text*

There are two fundamental tasks:

1. Toggling between showing "raw" urls and more human-readable versions.

2. Toggling between  elements and the pictures to which they refer.

Each involves *hiding text* while colorizing it. The wikiview plugin does 
this by setting point size to 0.1. Other approaches would be to alter 
fonts, pens or layouts in order to complete hide text. In any case, the 
guiding principle must be:

*The colorizer is never allowed to change text*

This principle can be paraphrased as:

*What happens in the colorizer, stays in the colorizer*

It would be suicidally bad design to allow the colorizer to change text, 
even temporarily. Doing so could cause time bombs that corrupt text.  We 
aren't going there, regardless of the complications in the colorizer itself.

*Strategy*
 
Hiding text should be straightforward:

- Several pattern matchers will change, in obvious ways.

- Pattern matches will *indicate *hidden text by calling colorRangeWithTag 
with "hidden" as the tag.

- Only setTag will actually hide text. As a prototype, setTag can color 
"hidden" text using a different color, say yellow.  The next step will be 
to use a small point size, as the wikiview plugin does. Finally, setTag 
might use do-nothing QFont, QPen or QLayout. setTag can do *anything*, 
provided that it *never *changes text.

*Handling pictures*

>From the docs for QTextImageFormat 
: Inline images are 
represented by a Unicode value U+FFFC (ord = 65532) which has an associated 
QTextImageFormat . Let's call 
such characters *picture characters*. 

I have just verified that this scheme allows multiple *different *images in 
text, each represented by the *same* picture character (ord = 65532). 
Presumably Qt maintains some hidden state. Leo will probably have to access 
this magic.

Pictures can be inserted into scripts, as long as they are in a comment. 
Tests show that Leo reads and writes picture characters correctly.  But 
that *doesn't *mean that picture characters will "just work".  In addition, 
Leo must do at least the following:

- Use uA's to associate replacement characters with images.

- Keep permanent references to pictures so they won't go away.

The colorizer can insert pictures characters as follows:

widget.insertHtml('' % path_to_picture)

This is an allowable (necessary) exception to the "no text changes" rule. 
The colorizer will have to check to see whether a picture character already 
follows each  element.

*Summary*

Issues #372  and #396 
 are two aspects of 
the same problem. The colorizer will handle both.

The colorizer will replace the wikiview plugin. Issue #388 
 is moot, and will be 
closed today. The wikiview plugin is deprecated, effective immediately.

jedit.setTag will hide text when called with tag='hidden'. It can hide text 
any way it likes, provided that it *never ever* changes text.

Hiding  tags will use the same machinery as hiding parts of urls. But 
full support for pictures will involve numerous complications. Happily, 
problems should be readily apparent.

All comments welcome.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.