On Thu, Mar 3, 2016 at 2:42 PM, john lunzer <[email protected]> wrote:
> > I do not think auto collapsing the tree should be default, it can be > disorienting and can destroy a workflow. > Not sure what tree you are talking about now. There are already various settings that affect how trees work. See leoSettings.leo: @settings-->Tree operation > > Here is my "aha!", I would still want the cloned results to be the focus > of my attention. Hoisting seems like a natural fit for this, adding a > settings option to auto hoist after any of the clone-find-all family > commands would give that focus. In my mind this would be an effective > solution to "views". There are some details that need to be handled though: > > - It would be great if there were an indicator that tells whether the > Tree is hoisted or not. > > Heh. I never thought of this. It's an excellent idea. > > - A search/clone-find-all history tab in the log pane would provide a > way to switch between multiple "views" quickly. By clicking on or > navigating to and activating (say by pressing enter) an item on the history > list it would perform that search as it was performed (memorizing whether > it was a cfa/cff/cffm/cfm) and auto hoisting or auto collapsing based on > which option you have set. > > A history might be good. Not so keen about re-running the search automatically. The clone-find commands are already very easy to do. Furthermore, after running them it's common to want to add and *especially* delete clones to refine focus. Redoing the search seems like overkill. It's not needed the way I do things. > > - Similar to above, a "Quick view" tab in the log pane would perform > similar cfa/cff/cffm/cfm searches as above except the items in this list > would be manually added. You could even send items from the > search/cfa/cff/cffm/cfm history to this Quick View tab, saving them for > later. > > Again, mechanisms for finding existing nodes are great. Automagic not so much. > > - A settings option should be added to remember your hoists when you > switch between clones. This way you can easily switch between the global > view and your hoisted view. > > This is pretty much what chapters *should* do. At present there is a completely brain-dead restriction that chapters must be children of an @chapters node. And we probably don't need @chapter nodes either: *any *node should be able to be the "base" of a chapter. So chapters, properly done, would give you what you want, I think. > > - This could easily be expanded to include any type of search (search > tags or any other type of attribute/predicate). > > *EKR Summary* Hoists are, or should be, similar to chapters. Clearly indicating the hoist/chapter status is a great idea. Perhaps icons could be added to hoisted nodes. There may be a better way. The new clone-find commands already solve all my problems. They can easily be run, and re-run. They don't interfere with each other. They create views, which can then be refined or hoisted. Leo is incredibly complex, and getting more so. We should add complexity only reluctantly. That's why the new clone-find commands are exciting. The complexity is hidden so they just appear to "just work" as I want. YMMV. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
