> > Hm? Languages?
Woops, I meant editors. The decluttering is still mostly a manual task? Setting the bookmarks, > cloning the nodes somewhere, etc.? Yes, it is entirely manual. You find what you want through searching and isolate it. There are some convenience functions to help with this particularly with clones which automate the find and clone process. One might say that a Leo outline starts automatically decluttered (collapsed to the root) and it is the users responsibility to selectively create clutter by expanding the outline. I don't see any other way to automate this decluttering, the important thing is that in Leo you can declutter where elsewhere you cannot. I think your question again points to Edward's recent ENB post about more advanced views of code and asking how we get there. I'm just stating the features as I know them, I'm not looking in any > direction here at all. Automatic updates of the outline according to the > code-structure > happens only when it imports a file. It does not update the outline when > it just saves it's outline. Having for example two functions in a node, > does not lead > to an automatic split of that node. So how good or bad the outline covers > the code depends solely on the user. And that's a point where tools like > folding > and tag-views have the advantage, because they don't force that work on > the user, but always display the actual state of the code without any > additional work > of the user. > I maintain that you're looking at it from the wrong direction and perhaps your view of what Leo is for is not correct. Leo isn't *forcing* the user to do additional work. The reason you're using Leo is because you *want* that control of the structure of the outline. Leo's primary functionality is not to parse a file and automatically break it up. However, it does do this during import at roughly the same level of detail as almost all other outline viewers I've seen. You could easily rebind Ctrl+S to a function which splits any nodes based on a def tag (or any other tag or list of tags of your choosing) and then saves your outline, without writing a plugin. Sometimes I want a node called "Helper Functions" (which is not reliant on the syntax of the language, which is a flexibility that outline viewers don't have) which contains three or four functions with less than five lines of source code each. Splitting nodes on a def tag would be custom behavior. Though I may eventually add this functionality into my refactoring plugin because it sounds quite useful. Along with a split-on-tag function a merge-on-tag function would be super useful as well. I see no advantage elsewhere even as an outline viewer, which again is a secondary function of Leo. However, I think you make a good point that there is a balance somewhere of having tools which help you generate structure and manually doing creating structure yourself. On Tuesday, September 22, 2015 at 1:55:59 PM UTC-4, Marcel Franke wrote: > > > john lunzer wrote: > > Unless i've overseen something, it only outlines structure, meaning >>> functions/methods and classes, and only at import-time. >>> Not loops, conditionals, comments and it does not update them after a >>> change in the body, only when it reimports from the file. >> >> >> I think this is looking at Leo in the wrong direction, ie, files that >> originate from outside of Leo. >> > > I'm just stating the features as I know them, I'm not looking in any > direction here at all. Automatic updates of the outline according to the > code-structure > happens only when it imports a file. It does not update the outline when > it just saves it's outline. Having for example two functions in a node, > does not lead > to an automatic split of that node. So how good or bad the outline covers > the code depends solely on the user. And that's a point where tools like > folding > and tag-views have the advantage, because they don't force that work on > the user, but always display the actual state of the code without any > additional work > of the user. > > >> This decluttering and reorganizing of the screen is powerful for me, so >> powerful that I've overlooked missing several features I really enjoy in >> other editors. If a person handles visual clutter and monolithic blocks of >> code well then Leo wouldn't have the same appeal and they may find it >> difficult to overlook anything Leo might be lacking. >> > > The decluttering is still mostly a manual task? Setting the bookmarks, > cloning the nodes somewhere, etc.? > > >> And that's just the point. My recent conclusion is that I think it would >> be a worthwhile effort to get some popular features from other languages >> into Leo rather than >> > > Hm? Languages? > -- 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.
