The abilities that Leo offers are used largely by professionals within the Leo community. As for why these abilities are not more common outside of the Leo community I'm not convinced that it is because the demand is low. I think this is a programming paradigm that is largely unknown/untested by even professional programmers.
Leo's stability in code manipulation is not prone to failure, it is very deterministic. Though I will agree that additional measures could be taken in dealing with external changes. I think a guided merge like those found in Git and SVN could help ease the frustration of bringing in external changes to arbitrarily changed code, but this is not a trivial task and not high up on the priorities list at the moment. I think it is a lack of "popular" features like linters and code-analysis/introspection tools (jedi or rope) that cause people to look over Leo. Ideally in time I would like to see these features in Leo, specifically I would like to see jedi integrated into Leo. It is claimed to be an easy to integrate library but I have not looked into it myself. On Tuesday, September 22, 2015 at 6:27:39 AM UTC-4, Marcel Franke wrote: > > > john lunzer wrote: >> >> From my short time testing out sr-speedbar (which keeps the speedbar in >> the original window) speedbar works opposite of Leo. It builds up an >> outline from parsing directory tree and source code of each file. This is >> immensely useful for navigation but it lacks the ability to specify >> arbitrary levels of code organization separate from the syntax of the >> source code. To that same effect it lacks pretty much every other feature >> of Leo where structure is created from the outline rather than the other >> way around. >> > > Of course, traditional coding-environments are aiming to be non-intrusive. > Tagbar and speedbar offer only a view on your data for the means of > navigation. they are not meant at all to manipulate the data themself. > Code-Manipulation is a problematic task, which can easily fail. Another > thing is that a pure view is more robust for changes. A tool like Leo which > enriches the structure with additional data can easily fail to fetch > external changes to code, because it doesn't know on it's own what it > should do with the data it has. A pure view on the other side just shows > the data as they are, and dosn't inflict further problems. > > BTW Besides the tag- and-project-view, there are also task-views (guided > by hints in the code like "#FIXME dosomething here"), linter-views (which > show failures, warnings and potential problems which tools like pylint or > pyflask have found) and bookmarks for faster navigation. So for a > professional coder there is not much demand for the abilitys Leo offer > there. The advantage is not big enough to put up with the disadvantages and > invest so much time to learn leo's ropes and corners. > -- 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.
