OK, just watched the video, I guess I should have before
previous comments ... I'd sound less foolish if.

I can see how well they work, however they introduce several new idioms:
- nodes in a body pane instead of the tree pane
- clicking in one part (empty space) of a body pane to put content there
- clicking in another part (button) of a body pane to change focus
- persisting is called 'layout'
- use of the top secret rclick on border

I want rclick menu to offer 'Bookmarks' option which creates a floating
pane, clicking on which would add the currently focused node.

I want rclick on a button in the bookmark pane to offer 'delete', 'rename' ...

I want Leo to save and restore this pane transparently


On Wed, Apr 8, 2015 at 9:55 AM, Edward K. Ream <[email protected]> wrote:
> 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.  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, 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.

-- 
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.

Reply via email to