Would it make any sense to put the shadow file information into Leo xml? Currently we have <v> ... </v> and <t> ... </t> what if there was an optional <e> ... </e> section where an 'e' node was 'external' or 'extra'
If found, it would enhance @auto nodes. Thanks, Kent On Wed, Dec 25, 2013 at 3:33 AM, Edward K. Ream <[email protected]> wrote: > 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. -- 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.
