On Wed, Dec 25, 2013 at 7:30 PM, Terry Brown <[email protected]>wrote:
what's the advantage of the conversion from > > bookmarks to clones? > First, it suits me. It's my preferred way. Second, it allows me to focus on all and *only* the nodes of interest. And I can use the search command on only those nodes. This is not possible with bookmarks. Third, all Leo's normal keystrokes, including arrow keys, allow me to navigate between the clones *quickly*. 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. > This extra context is precisely what I *don't* want. It had better be the case, generally, that the context of the node *doesn't* matter. If it does, Leo's design is broken. 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. > This is the crux of the matter. Not only do you need the mouse (or yet more key bindings), but what you get isn't even close to a proper view of the task at hand. For example, the recent fix for the per-clone expansion problem started out with a clone-find-all for isExpanded. That created dozens of clones. In a bookmark-centric workflow I would lack at least the following *crucial* capabilities: 1. Organizing the clones into categories. 2. Searching all and only those clones. 3. Seeing the clones in a compact area. > 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. > I am not interested in improving the key bindings in the bookmarks pane. At best, you get something approximating Leo's existing key bindings, without *any* additional capabilities. 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. > Again, I have zero interest in this. Why duplicate a hierarchy in yet another pane, when converting bookmarks to clones instantly gives all the advantages of Leo's full-fledged outlines? To summarize: 1. We agree that collections of bookmarks/unl's is a fundamentally important capability. Packing and unpacking trees of clones is something that Leo should have immediately. 2. Imo, your remarks about bookmarks highlight their weaknesses, not their strengths. 3. Clones will always be my strong preference. It's fine with me if you prefer bookmarks :-) As usual, it is pointless to argue about preferences. 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.
