Looking over my should while I add support for jedi autocompletion

[Edward K. Ream]

Chris George said he would like to look over my shoulder while I do #309: Add 
support for Jedi autocompletion. 


It looks like a plugin will not be needed.  Instead a new setting, say 
@bool use_jedi_autocompleter, should suffice.

I'll document most of my work in #309 itself. GitHub issues allows easier 
formatting of code and much easier editing.

Here, I'll just discuss a few preliminaries.

*Step 1: Create jedi.leo*

This allows me to go right to the sources with any questions.  See the 
leo-editor-contrib  repo 
for jedi.leo.

Note: There was a problem importing parser/token.py. This arose because a 
leading '@' sign in the opmap_raw docstring confused the importer.  This 
might be called a "lucky bug" because it reminds me that jedi does not 
understand Leo's "extra" syntax.  Otoh, that may not be so important...


*Step 2: Read the docs*
This step is a bit disappointing.  The API docs are here 
.  
The starting point is the example:

>>> import jedi>>> source = '''... import datetime... datetime.da'''>>> script 
>>> = jedi.Script(source, 3, len('datetime.da'), 'example.py')>>> 
>>> script>>> completions = script.completions()>>> 
>>> completions [, 
>>> , ...]>>> print(completions[0].complete)te>>> 
>>> print(completions[0].name)date


The docs say: "As you see Jedi is pretty simple and allows you to 
concentrate on writing a good text editor, while still having very good IDE 
features for Python."


In fact, this example is probably good enough, but it took awhile to 
understand that.  Learn by doing, etc. I'll have a lot more to say about 
this example in #309.


*Summary*


I'll continue this discussion in #309 
 itself.  All comments 
and questions welcome, either here or in #309 
.


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: Second thoughts about new positions

[Edward K. Ream]

Here are some second thoughts about changing Leo's Position class.  They 
are likely valid regardless of the specific details of the proposal 
.

The advertised benefit of new positions is that they remain valid after the 
underlying tree of vnodes changes. This post discusses why this benefit 
will be less impressive than it might at first seem.

*Potential problems do not affect he new reading code*

I am a big fan of the proposed new reading code 
. Imo, Leo will benefit 
greatly from this code.

The new read code and the new Position class are completely separate 
projects. The new read code might use new positions internally without any 
problem whatever. This post discusses potential problems with using new 
Positions "elsewhere", that is, in general Leonine scripts.

*Potential problems with new Positions*

I foresee at least the following problems with new positions:

1. They will not help synchronize positions across separate invocations of 
Leo.  That is, they can't simplify Leo's PersistenceDataController class. 
In particular, pd.find_position_for_relative_unl and its helpers will 
remain unchanged.

2. They are unlikely to help simplify c.deletePositionsInList.  Whatever 
the representation of positions, the strategy contained in this method's 
docstring are likely to remain in force. Here it is:

Step 1. Verify, *before *making any changes to the outline, that all the 
positions passed to p.deletePositionsInList *initially *make sense.

Step 2. Treat each position as a "request" to delete *some *vnode from the 
children array in the *position's* parent vnode.

3. In general, it's not clear (to me) what "persistent" positions would 
actually mean once an outline changes.  When caching tree-related data, 
most scripts (including Leo's core) actually cache vnodes or gnx's.

4. New positions are likely to suffer large performance gotchas. The double 
indirection involved in accessing new positions will not remove this 
gotcha.  Unless I am mistaken, changing the tree will involve updating all 
"inner" positions, that is, all the targets of the indirection.  This will 
likely be an O(N) operation, where N is (twice) the number of nodes in a 
fully expanded tree. In contrast, updating the tree presently takes O(1) 
time.

*Summary*

The new read code is free to use whatever internal representations it likes.

I see no benefits to using any new Position class. There would likely be 
performance gotchas.

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.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

On Tue, May 15, 2018 at 5:04 PM, vitalije  wrote:

About script compatibility and rewriting Position class, I was thinking
> that it would be simplest thing to just let them be as they are now.
>
​...​

Both models can easily coexist. We can advice all users to write their
> scripts using new patterns and strategies to take the advantage of new
> model. But they can keep old scripts if they like.
>

​An interesting approach.  I'll have more to say about this particular
topic in my next post.

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.