On Mon, Jul 14, 2014 at 10:41 AM, 'Terry Brown' via leo-editor
<leo-editor@googlegroups.com> wrote:

> So how hard does the new code try to recover from breakage?

At present, Leo attempts no error recovery.

> Does it use the new indexed UNLs to fall-back on position index when 
> headlines fail?

I have no idea what you mean by this.  If a bookmark (unl) can't be
associated with a node (headline) then the node's gnx doesn't change:
it won't be a clone of any node an it won't have any uA.

> I guess it's a more sensitive case than bookmarks, where Leo can basically 
> say "I can't find that, but it used to be here, if that  helps", and let the 
> user decide.

That might happen later.

> In the import case you could only
> fall back on the position index when the matched node was not also
> matched by a headline list.  I.e.
>
>     class Foo
>        def __init__
>        def otters
>        def recieve_data
>        def send_data
>
> if it's simply a change from recieve_data to receive_data, falling back
> on position index would be great.  But if the change was to
>
>     class Foo
>        def __init__
>        def otters
>        def send_data
>        def receive_data
>
> then headline search would fail and index search should fail because of
> the competing headline search match for send_data.

All of this is what I am calling AI.  I would prefer not to do
anything in such cases. At what point does an (obvious???) misspelling
turn into a "real" change.

Rather than try to answer such deep questions, I would prefer to
accept the inevitable:  some links to gnx's will break.  It would be
easy to report such breaks, as you suggest.  In fact, pd.restore_gnx
will do this if the trace var is True.

> Also, does the new code use the new UNL's repeated headline count to match 
> the right headline when headlines are repeated?

No.  That's on purpose.

> Repeated headlines in python code would be contrived, e.g. [snip]

I agree.  Pylint will report duplicate function/method in such cases.

> but repeated headlines in other languages might be entirely reasonable,
> "div" in parsed HTML being a trivial example.

Interesting.  Imo, the solution for html would be to add more to the
imported headline :-)

> So when breakage does occur, does the new code make a list of nodes not found 
> with their uA data still attached?  Because that could be really useful when 
> valuable uA data was involved.

Interesting idea.  pd.update_after_read_foreign_file could easily
create a list/tree of nodes with potentially valuable uA's, with
headlines derived from the unmatched corresponding unl in the @gnxs
node.  This would work much like the "recovered nodes" nodes that Leo
creates when reading @file nodes.

Having said that, my experience is that such recovered data are rarely
used, even when the data are text.  I suspect recovered uA's would
hardly ever be used.

> Are gnxs persisted?

Yes.  The @gnxs node contains pairs of lines associated the
(persisted) gnx's with unl's.  If the match is made, pd.pd.restore_gnx
restores the gnx of the imported node by calling
p2._relinkAsCloneOf(p1).  It's slick.  If the match can't be made, the
node retains the (new) gnx given to it by the importer, with a
timestamp that reflects the time that the node was imported.

> What are the differences between this and @shadow?

Good question.  @shadow recreates the outline using the Leo sentinels
in the so-called private file.  All gnx's (and so clone links and
uA's) are preserved.

@shadow works by diffing text, namely the diffs between the public
file and the private file (stripped of sentinels). The public file
never has any sentinels, so all changes to the public file get
translated into text in the original nodes in the private file. With
@shadow, all changes to the outline structure, **no matter how big**,
are "shoe-horned" into the outline structure of the private file.

In contrast, the @auto importers have no access to any sentinels.
They create a tree based solely on the logical structure of the
imported file.  In particular, headlines in @auto files can only come
from the names of functions, classes and methods.

Aside:  The old "new @auto" code tried to rename/retain headlines, but
that created way too many complications.  I have no plans to bring
that scheme back.

In short: @auto always give you the correct structure of the imported
file.  The @auto importers know nothing of gnx's. @shadow always
preserves the structure of the outline when it was last written,
including gnx's.  That may not be great when big changes have been
made.

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to