On Wed, Apr 8, 2015 at 8:30 AM, 'Terry Brown' via leo-editor < [email protected]> wrote:
When I was thinking about clones the other day I realized they're very > peer to peer, there's no way Leo can easily distinguish the 'original' > from the 'copy', even though we clearly thing the one in the @<file> > tree is the original and the one in the view tree is the copy. > Yes. Internally all clones are actually the exact same vnode. However, we can distinguish between *positions *of vnodes. A clone in an @file tree could be treated differently from its other clones in other areas.* We have only just begun to explore the possibilities.* I've just finished re-watching your bookmarks video <https://vimeo.com/77720098>. It's excellent. Reactions below. So there might be ways to allow find to know what to report and what to > skip, but everything that parses the outline would have to make the > same checks against false / duplicate hits. > In my ENB reply in this thread <https://groups.google.com/d/msg/leo-editor/ArCFlvSjtPo/XY6n_Lv4MB8J>, I mentioned that recent developments re command history have shifted my thinking. This has created an avalanche of ideas. See below. The key idea, imo, is to *distinguishing nodes or contexts*. To repeat, we have only just begun to explore the possibilities. In effect, @button cfa-Code @args add limits the clone-find-all-flattened command to the top-level code node. We could apply these ideas to bookmarks! So the better solution might be to attempt to convince Edward that > bookmarks can take the place of clones for the creation of views :-) > You already have, modulo minor concerns. I like how bookmarks work, but I don't like using the mouse to shift nodes.* The bookmark pane should not be necessary.* Leo's tree is the best organizer possible. I am going to play around with bookmarks immediately, treating any required mouse clicks as symptoms that bookmark commands are missing. (If they are missing ;-) In other words, I'll treat the bookmarks pane as a prototype, not as any real limitation of bookmarks themselves. I could have done this long ago, but now the way forward is much clearer: 1. I want a *distinguished context* to form the *anchor *of bookmarks and their commands. Perhaps it already is possible. Could be done with @button/@command or it could be a side effect of one or more bookmark commands. This anchor should eliminate mouse clicks from bookmark commands. The bookmarks-mark-as-source could create the anchor explicitly, if need be. This command is somewhat similar to bookmarks-mark-as-target. 2. I want a command to select the "my bookmarks" node in the video. Say bookmarks-select-source-bookmarks. Additional ideas below. 3. Once the user selects the container node selected, normal Leo commands can navigate to the desired bookmark. 4. Now I want a bookmark command (it may already exist), say bookmarks-go, to simulate a left-click on the bookmark in the bookmark pane. Again, no need for the bookmarks pane! The video shows various manipulations of tags in the bookmark pane. All could replaced by actions on the child bookmarks of the bookmarks node The only drawback to using bookmarks is that selecting a bookmark node shows you neither its body pane nor its children. Otoh, the body text is a great place for description, notes, etc. Furthermore, renaming bookmark nodes (rather than their target nodes) can be very handy. 5. Pre-loaded, *outline-specific *commands in Leo's command history amplify the effect of the commands discussed above. No need for lots of key bindings. Better, no need to laboriously jump around the outline. A pre-loaded, outline-specific @button command can simply select the desired bookmark anchor. It's one line of code. The @button command is *dynamic *because it is local (outline specific). When my desired set of bookmarks changes, (when I want to focus on another task) I can simply change the target in the @button node. No need to reload the outline. The changes take immediate effect. This is look promising and easy! A big day for Leo... I'm assuming I know what a view is, a > > collection of nodes pulled from > elsewhere that are collectively the nodes needed to work on a problem. > Correct. > Bookmarks can certainly handle that application, perhaps I need to make > a better bookmark video. > Your video is fine. Watching it again at this creative moment was perfect. Edward P.S. There will always be a need for clones, because they really are *hard* links, which is essential when using clones in a data-oriented way rather than a search-oriented way. EKR -- 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/d/optout.
