On Sat, Jun 18, 2011 at 9:37 AM, Terry Brown <terry_n_br...@yahoo.com> wrote:
>> 1. The goal is to increase the number of Leo's users. >> >> This is really the *only* goal. Leo is already good enough for what I >> do, so Leo 5.0 must focus on what others might want. > > Not sure how this relates to points 2-5 :-) It relates only in so far as it may reduce the "pollution" of source files. > I think one click install would do more to increase the number of Leo users > than anything else. Yes, that would certainly help. >> 5. Patterns (and other techniques) can define views. > > I think there's potential here but not sure if there's a single simple > way of making views - not that you're suggesting there should be, but > just pointing out that ways of generating them may be as varied as > their uses. Which are not, of course, restricted to ways of looking at > source code ;-) The idea of creating the soft link automatically when the user drags a node under an @view node relates to your next point... > > UNLs UNLs UNLs > > don't get anywhere near as much credit as they deserve. In essence, my posting is groundwork for giving UNL's their due. Soft links, like UNL's, can fail. The point of my posting is that isn't necessarily such a bad thing: provided we don't expect view nodes to carry uA's. > Personally I think [UNL's] can replace clones and > eliminate all the complexity clones introduce, but I don't expect that > to happen :-) This is why I emphasized point 4. Internally, Leo's data structures are "perfect", stable and capable. So *internal* clones (Leo's DAG) is not going to change. But from the user's point of view, the Aha is that I don't use clones that require uA's, so soft links, @view nodes, etc, would do as well. > I use leo/external/leosax.py to zip through a list of 20-30 .leo files > and generate a view of all the todo nodes found therein. The script > builds the view so that there's a node for each file searched, and > below that a kind of sparse tree of all the todo nodes found in the > file, which maintains the hierarchy among todo nodes, but ignores all > others. It is exactly this kind of script that could be built into an @view-pattern node (automatically by Leo) or built into an @view-script node (on a custom basis, by the user). The point is that Leo's read code would execute this script automatically on loading one or more .leo files--the scripts would populate their respective @view nodes. > So: > - don't forget UNLs > - leosax can parse dozens of .leo files in seconds, the time is in > building the view tree, not parsing the files. It does not expand > @file nodes (which I don't use) > - there are lots of kinds of possible views, of source, of summaries > of .leo files as above, of database records, etc. > - don't forget UNLs Thanks for all these comments. Imo, we are saying very similar things. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
