On Thu, 9 Apr 2015 03:41:42 -0500 "Edward K. Ream" <[email protected]> wrote:
> > On Wed, Apr 8, 2015 at 11:23 AM, Kent Tenney <[email protected]> > wrote: > > > > > 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 > > > > Despite Terry's answers to this, I have similar concerns. > > In fairness to Terry, is a hard design problem, and potentially a lot > of work. > > Let's do a thought experiment. > > Suppose the bookmark pane looked and worked like Leo's existing > outline pane, except that the nodes were bookmarks. Let's call this > the *bookmark outline pane*. *Optionally*, there could be a* bookmark > body pane*, containing data associated with each bookmark: notes, > explicit UNL's to the target node, whatever. Rather than a bookmarks body pane, it would be better to spend time on the "body editor as a relocatable widget" project that's been drifting around for years. If that was done, it would be trivial to have an editor showing the bookmark's body. The bookmarks pane is basically a tree view, although it works horizontally as well as vertically. As you know from reading Plugins -> Bookmarks -> About ;-) there are commands to use the bookmarks from the keyboard: General bookmark commands bookmarks-open-bookmark opens the bookmark in the selected node if the node has an ancestor which contains @bookmarks in its heading. bookmarks-open-node, like bookmarks-open-bookmark but without the ancestor requirement. bookmarks-switch move between your working position in the outline, and the current bookmark, in the outline. This is the keyboard friendly no extra pane alternative to the mouse based bookmark pane navigation described below. bookmarks-bookmark Add the current node as a bookmark at the current level in the bookmarks tree. Another keyboard friendly alternative. bookmarks-bookmark-child Add the current node as a child of the current bookmark, if there is a current bookmark. Another keyboard friendly alternative. Real estate wise bookmarks require very little in a horizontal orientation, just about two lines off the body panes area typically. Really the only things I've heard that I don't think is largely covered is bookmark body view, which would be best addressed by relocatable body widgets, and keyboard navigation in the bookmark pane. That would be a nice feature to have - you can navigate bookmarks with the keyboard now with bookmarks-switch, but a command to focus the bookmarks pane and use cursors keys and enter in there to navigate would be nice. Cheers -Terry > *How useful would this be*? > > There would be many advantages. The appropriate key bindings would > be in effect, so one could navigate, expand and collapse, organize, > create and destroy nodes as usual. Creating a node would, > presumably, create a bookmark. You get the idea. > > Navigating the *bookmark * > outline pane would *select *the corresponding node in the main > outline, which would update the main body pane. If the bookmark > outline pane also contained a bookmark body pane, this pane too would > automatically update. *Important*: when navigating the bookmark pane, > focus would stay in the bookmark pane even though the nodes in the > outline pane are also being selected. > > This is pretty much the way present bookmarks plugin works. In > particular, selecting a node in the outline shows that node in > context, a very good thing. > > Despite all the coolness just described, this platinum design has a > few drawbacks. > > 1. This design takes a lot of real estate. I hadn't originally > intended to mention it, but the design is looking good enough that it > now seems important to point out this drawback explicitly. :-) > > 2. This design implies constant switching back and forth between the > main outline and the bookmark outline. A new > toggle-active-outline-pane command would work, but we would be using > it a lot. > > 3. It's easy to blithely talk about how focus will stay in the > bookmark panes while also Leo selects nodes in the body pane, but > this will be very difficult to do. We are talking about messing with > some of the most complex logic in all of Leo. The present bookmarks > plugin finesses this problem by never having focus :-) > > *Summary* > > This design could work. When I started this reply I didn't realize > how good it could be. It would take lots of real estate, and lots of > tricky code, but it's not out of the question. > > Leo's history might have been very different had I started with > bookmarks instead of clones. > > However, there is another question to ask. Is it possible to improve > Leo's find commands to eliminate unwanted hits during searches? I'll > discuss this in another thread. > > 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/d/optout.
