On Mon, Dec 16, 2013 at 9:03 AM, Terry Brown <[email protected]>wrote:
> I have some unpushed changes to bookmarks.py that make it use an UNL
> rather than a gnx to keep track of the node which holds the bookmarks
> for an outline.
>
To answer your question in the headline, bookmarks are, or soon will be,
the long-awaited breakthrough in collaboration. Imo, it is almost certain
that they will be the basis of Leo 5.0.
Yes, I've said similar things about several other features lately (@shadow,
@auto and maybe one or two other things), but this time the odds are much
higher than before.
As you have said in several places recently, bookmarks have several
advantages over clones or gnx's. This has created an avalanche of ideas.
Just slight extensions will make them much more powerful.
The following "wish-list" items may exist already, but even if they don't
they can be implemented in hours, not weeks. Only mundane invention will be
required to create spectacular effects.
All of the following ideas come directly from you, Fidel, Rob et al. I make
no claim of invention:
1. A way of turning a "tree" of bookmarks into a tree of clones.
2. A way of turning a tree of nodes into a tree of bookmarks.
3. A way of reorganizing a newly-imported @auto tree using a tree of
bookmarks.
4. A way of generalizing the search for a bookmark.
> This means the list of bookmarks for outline A can live in outline B.
This is hugely important, especially considering point 4 above (discussed
below). We now have a *proper* way of making cross-file references that has
nothing to do with gnx's.
You raised the key idea in another thread: bookmarks break less often than
either positions or gnx's.
In particular, the child index of a node *doesn't matter* as far as a
bookmark is concerned.
It will be *trivial* to make bookmarks almost unbreakable. Let ?--> denote
a **searchable link** to a node. Such links create **generalized
bookmarks**. For example::
leoPy.leo#?-->leoApp.py?-->class
LoadManager?-->LM.computeLeoSettingsPath
This bookmark will cause Leo to search leoPy.leo for leoApp.py, then search
that tree for class LoadManager and then search that tree for
LM.computeLeoSettingsPath.
In effect, ?--> is a synonym for g.findNodeInTree!!!
Even grand reorganizations will not break such links!
We could generalize further, by allowing ?body--> to search for particular
body text in a give tree.
This means that you can have your own private set of bookmarks (which
> are an alternative to clones for tracking current work / nodes of
> current interest).
>
Yes. This turns out to be hugely important.
Recently,
https://groups.google.com/d/msg/leo-editor/xChTCAoRwck/B5z-cNdz4McJ, Rob
discussed sidecar *files* as a way of transporting additional structure.
We can now see that bookmarks are the perfect sidecar *data*.
This data can, and usually will, reside in a .leo file, but they could be
exported/imported as text files, possibly with a special file type.
Now let's talk about point 3 above (A way of reorganizing a newly-imported
@auto tree using bookmarks)
Because generalized bookmarks seldom break, one can *expect* to be able to
reorganize incoming @auto files based on a tree of bookmarks. For example,
one could "declare" that methods x, y and z (defined by bookmarks!) of a
particular class are setters. And those setters should have their own
organizer node! Details murky, but *clearly* this can be done. This will
be a project requiring days, not weeks.
The great beautify of this scheme is that make *zero* demands on external
markup. Everything is self contained within the "sidecar" data in the .leo
file. And yes, this "view" of an organization can be shared (via private
channels) with other Leo users!
For example, I could set up leoPlugins.leo so that it displays
> bookmarks for plugins that interest me, without any modification to
> leoPlugins.leo itself. An entry in c.db, which is local to me, records
> the fact that plugins for leoPlugins.leo are at
> /home/tbrown/.leo/workbook.leo#Bookmarks-->LeoPlugins
> When I change the bookmarks for leoPlugins.leo, those changes actually
> occur in workbook.leo.
>
> I think this is very cool, but apart from leoPlugins.leo /
> LeoPyRef.leo, when would it be useful? Anytime you're sharing a .leo
> file between people who have different areas of interest within that
> file. So I guess the question is, how common is that?
>
The "interconvertability" between bookmarks and clones is hugely
important as a fundamental technology.
>
> Bottom line I need to see if the new implementation's solid enough, if
> it is then there's no reason not to push it, otherwise it might not be
> worth it.
>
It's a huge conceptual breakthrough.
Obscure note: Strictly speaking the bookmarks could be stored completely
> in c.db and bookmarks would have been cross file from the beginning,
> but I think the tendency is to store a minimum of expendable, light
> weight pointer type info in c.db, I'm certainly more comfortable with
> bookmarks being stored as nodes where they're more interactive and
> better covered by backups etc.
>
Imo, it would be much better to make trees of bookmarks "first class"
objects. Why hide this wonderful, and intuitive technology?
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.
