On Tue, 18 Aug 2015 10:39:45 -0700 (PDT) [email protected] wrote: > Hi Edward, > > I don't know how often this has been asked: > What if options would not be set via head or body of a node but be > attributes of this node?
I think what you're suggesting would be, in Leo terminology, putting the directives for things like rst processing into the oddly names "unknownAttributes", or v.u (a.k.a. p.v.u) dictionary for storing arbitrary key/values pairs on a particular node but not in the headline or body text. The attrib_edit plugin lets you store node specific attributes this way, in fact three ways, but one way is in the p.v.u dictionary. It's used by the xml_edit plugin. attrib_edit adds a pane (or tab in the log pane) displaying each nodes attributes. Not that it doesn't display everything in p.v.u, just things identified as attributes. So technically Leo already has the machinery for what you're suggesting. But directives have always been represented as text in the headline or body. In some ways the recent declutter work is a way of maintaining that long established pattern but not having it taking up screen space when you don't need to see it. To do what you're suggesting and maintain backwards compatibility I could see some sort of DirectivesManager class which provides information on the directives specified for a particular node, fetching them from either head / body @text or p.v.u. So sub-systems (like rst handling) upgraded to use it could work either way. But there would be a lot of codebase wide changes, and it needs more design thought. It's possible and not unreasonable, but not trivial. My response above is about an alternative handling of the representation of directives for example for rst. Some of your other comments seem to describe role specific node viewing and editing. Really there's quite a lot of the going on in Leo already. The todo plugin is an obvious example, but bookmarks, active_path, graph view, view-rendered etc. are all variations on this theme. Cheers -Terry > Of course not Class attributes but attributes of specific instances > to keep everything smaller. > > Why I'm asking: > > Today I tried to integrate my code nodes into my yet to be written > bachelor-thesis. > And I found out: > 1) how shortsighted I am (unfortunately a often returning insight) > 2) how to do it > > Besides being superhappy now I still wonder about the way to set the > options. > > One benefit would be > (aside from having a cleaner tree and using title and body for what > they are, that is title and body) > that one could imagine other viewers of the codebase. > > For example one could have Nodes for developers or versions or > dates...... > > A viewer that would help with project development would then > associate developers and their written code. > A viewer that would help with project management would organize tasks > or calendars or dates or whatnot. > A viewer that would help with file management would show directories > and files (and maybe lines or shapes or sounds ....) as nodes .... > > What do you think ? > > Have viewers that can not be sure that a certain attribute even exist > but try nevertheless? > > Stupid and useless or worth it ? > > Greetings, > > Holger > > Am Mittwoch, 29. Juli 2015 15:07:44 UTC+2 schrieb Edward K. Ream: > > > > In my mind, all essential aspects of Leo are complete. Sure, there > > will always be improvements to be made, and I intend to keep making > > them, but now that that we have @clean the most important work is > > complete. > > > > Imo, Leo is good enough as it is. What's not so good is outreach > > to the rest of the world. Marketing, if you will. > > > > An excellent suggestion is to reach out to magazine editors, get > > them excited, and have them write or commission articles about > > Leo. I think this is a great idea, but we haven't made much > > progress on this front. > > > > Recently I've been thinking about creating "true" Leo modes for > > emacs and vim. This would be a lot of work. In essence, this > > would create Emacs and Vim guis. All other code must remain the > > same, and the gui must (mostly) be written in Python, not elisp or > > vim script. > > > > Your comments, please. > > > > 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/d/optout.
