On Tue, Dec 24, 2013 at 6:02 PM, Terry Brown <[email protected]>wrote:
> On Tue, 24 Dec 2013 14:24:45 -0800 (PST) > "Edward K. Ream" <[email protected]> wrote: > > > My present opinion is improving @auto is feasible technically, but > > infeasible in practice. > > > > The killer problem: sections and organizer nodes are not possible without > > comments of *some* kind. > > > > I think this is correct - clever whitespace tricks will get cleaned > away, comments that don't provide real information likewise. There's > nowhere to hide metadata in the source files. > Ok then. It's time for me to let go of my attachment to various "tricks" with external files. The bottom line: if one's co-workers can tolerate sentinels of *any* kind, then @file suffices. Otherwise, we will have to use @auto and @shadow as they presently exist. > > Your comments, please. > > If there's nowhere to hide the needed metadata in the source files, it > follows that some secondary communication path between Leo users would > be required to share the metadata if it was maintained separately, i.e. > @shadow. So we could look in to what would be needed to make that > easy, although I'm not sure if it's worthwhile at present. Currently > using @shadow they'd need to exchange the shadow files, which is > currently tricky but could be made simpler if it seemed worthwhile. > A recent Aha is that @shadow really isn't a "communication path" for sharing structure. Instead, it is a way of shoe-horning someone else's structure into the local structure that @shadow recreates. So, imo, @auto is actually the best that can be done in synching changes to structure. > My feeling is that bookmarks as demoed in my bookmarks video are > actually easier to use than clones, and achieve the same thing, but in > a more lightweight way - in the case where clones are used > as demonstrated in your using clones demo video. > Your comment suggests a bright new way forward. It's time for me to investigate the potential of bookmarks. I have not really done so before now. Yesterday, I was initially annoyed and upset that @auto could not be radically improved. Now I see that letting go of infeasible solutions, and my attachments to them, will permit me to consider much more promising alternatives. If you were using bookmarks rather than clones, Leo users would just > need to exchange a Leo file to exchange their view of the interesting > part of a source tree. Or even just include "@file Leonards_view.txt" > and "@file Liams_view.txt" in their personal Leo files, just exchanging > the `@file`ed .txt files. > One could even imagine exporting and importing leo-bookmark files. Fidel's ideas about hierarchical bookmarks might allow bookmarks to > behave as alternative options for both clones *and* organizer nodes - > which is interesting to think about. Actually bookmarks can already by > used in the tree-view hierarchically with organizer nodes, but the UI > for managing them that way, both graphically and key binding wise, > could be better. > I think this is a good template for further improvement. I haven't actually ever used bookmarks, because clones always have seemed better. But recently I have begun to notice some not-quite-nice features of clones: 1. Because of clone wars, I don't like to keep permanent copies of clones in places other than the .leo file in which they reside. In particular, I have begun to eliminate them from leoProjects.txt, and I am not particularly fond of them in leoNotes.txt either. 2. Clones complicate searches. I have contemplated adding a "ignore duplicates" checkbox in the Find Tab to handle this problem, but such a "solution" has its own problems. Leo will *always* support clones. Given that simplifying sentinels will never appease their critiques, it makes no sense to eliminate gnx's from node sentinels. However, replacing clones by bookmarks in typical workflow does promise real benefits. Earlier you said, "My feeling is that bookmarks as demoed in my bookmarks video are actually easier to use than clones". I don't have this sense yet, perhaps because I don't grok one or more essential features of bookmarks. I am going to experiment using bookmarks instead of clones. A good place to start the comparison is with fixing the problems with per-position expansions. At present, I have are several dozen nodes involved in the hunt, organized in three or four organizer nodes. This should bring me up to speed with the latest bookmark features and Fidel's ideas. Of course "bookmarks" are just UNLs, and they can break, but usually > they don't, they can often be fixed (and we could potentially develop > tools to make fixing them smarter), and they have zero impact of the > files into which they point. > A very important comment. Clones depend on gnx's; they break without sentinels. Positions depend on child indices; they break when any part of the position moves in any way. Not so with unl's: you can freely move change the child index of any item in a unl without breaking the unl. I have been thinking of the implications of this since I first read your reply. Many, many thanks for these comments, Terry. You have made it much easier for me to step over the wreckage of the @auto project and move on. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
