On Wed, 25 Dec 2013 16:15:25 -0600 "Edward K. Ream" <[email protected]> wrote:
> On Wed, Dec 25, 2013 at 3:06 PM, Terry Brown <[email protected]>wrote: > > > > > Something like that. We need a container for bookmarks. > > > Not sure about the name. @clones? @view? > > > > @bookmarks ? :-) > > > > I avoided that name because the bookmarks plugin already uses it for > another purpose. The behavior of @view would be different: it would > "expand" to a tree of clones--one per found bookmark in @view. So just a question - what's the advantage of the conversion from bookmarks to clones? If you have 3-5 clones of nodes containing code of current interest, you can edit those nodes by moving between clones without having to navigate around the tree to get between them. You can also see the descendants of the clones. But bookmarks give you the same advantages, with even more complete context for the nodes you're editing, you see the node in its full normal context, so you see siblings and parents as well, which may be useful. Of course, this requires some way of navigating between bookmarks, which is currently primarily mouse based and using an additional (small) pane, but it wouldn't be hard to add key-board bookmark navigation, and approaches which don't involve an additional pane are possible, although I think the extra pane has advantages. I guess you have to "look up" the bookmark, whereas the clone can be edited immediately, but the right bindings / actions for bookmarks could make that look up almost weightless, and clones have costs in terms of complexity that you've already covered. So that's the general thoughts - the nitty gritty would be looking at the bookmarks demo video as a starting point / context. There, navigation between bookmarks is by clicking on them in the additional pane. But all that's needed to make it a keyboard friendly thing it to mark a bookmark as the 'current' bookmark (i.e. the last one 'used'), and have bindings to select the next / previous. This approach could work with the extra pane (some graphical marking of the current bookmark would be easy), *or* the regular tree view. When you use the key bound to 'bookmarks-next', the next bookmark is selected, hitting some other key, maybe Enter, maybe not, jumps to the bookmark. Hierarchical bookmarks will fit fairly simply in this framework as well, I think. Using the extra pane, there could be multiple strips of bookmarks, where the second strip shows the bookmark children of the current bookmark in the top strip, etc. In the tree view, it's simply node hierarchy. Cheers -Terry > These are early days for the design. One idea: use something like yaml to > designate a tree containing the clones. > > 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.
