On Tue, 24 Dec 2013 14:24:45 -0800 (PST) "Edward K. Ream" <[email protected]> wrote:
> > (Terry) So will @auto still have close to zero impact on collaborated > files? > > (Matt) It would be very tempting to delete something like this. It looks > like a mistake or just some random unneeded cruft. > > 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. > 3. It was interesting to consider reconstituting clone links using unl's. > > In summary, a beautiful idea has been killed by an ugly fact. Worse, @auto > was the last hope for truly convenient collaboration among Leo users. As > it stands now, people who want to use Leo in a collaborative environment > must endure the deficiencies of @auto. > > 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. 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. 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. Clones and organizer nodes are separate things, but the lack of place to store metadata eliminates both of them. Currently bookmarks only have clone like behavior. 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. 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. Cheers -Terry -- 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.
