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.