On Thu, 10 Jan 2013 08:41:16 -0800 (PST) "Edward K. Ream" <[email protected]> wrote:
> On Wednesday, January 9, 2013 4:56:37 PM UTC-6, Edward K. Ream wrote: > > I think it would be useful for Leo to write, at the start of each external > file, the name of the .leo file that wrote it. This would be the short > file name, x.leo, not the full path. This is, imo, enough of a clue :-) > Sometimes that clue comes in handy: there are a surprisingly large number > of .leo files on my drives, and I often don't remember which .leo file is > responsible for creating the external file. This clue is particularly > valuable when I use Leo to study somebody else's code: there is then no > obvious way to remember the name of the .leo file that created the Leo > sentinels. > > Your comments please. So you're talking about adding metadata to the info. in the sentineled file formats. Downsides: - more visual cruft to ignore in other editors - backwards compatibility issues for earlier versions of Leo Upsides: - helpful when you're looking at a file outside of Leo, maybe I don't think the visual cruft issue is a big deal, a) there's already a lot of annoying visual cruft in other editors when looking at sentineled files, so a bit more won't matter, and b) I don't use the sentineled file formats anyway :-) The backwards compatibility issue seems like a bigger deal, is someone going to find they can't ready a @file node in 2013-01-03 Leo because it was written in 2013-01-20 Leo? Is the upside enough to justify this? Or can the current format include the info. with out breaking read in older Leos? Iff you do add it, I'd argue for adding a) the time of write as well, and b) making sure the mechanism is extensible so other metadata can be written in the future without backwards compatibility issues, if they even exist now that is. Cheers -Terry > > Rev 5553 allows g.trace and g.pr to work when leoGlobals.py is used in > standalone mode (g.app is None). > > More work is coming. I would like to eliminate the hack of initially > assigning g to a nullObject instance. I understand that this hack makes > life a tad easier for one or two plugins, but the present code depends on > Leo itself to set the g var. This seems wrong, and makes leoGlobals.py > much less useable than it should be outside of Leo. > > The latest revs to leoGlobals.py are a half-way measure: they remove the > "g." prefix from the code for g.trace and g.pr and a few other helpers. > This is a general solution, but I don't actually want to remove all the > "g." prefixes from leoGlobals.py because a) I automatically type g.trace > and b) using g.trace allows me to set the trace flag. If I were to change > g.trace to trace, I would have to change trace to something like > trace_flag. So I want another way. > > Ideally, I would like to eliminate the "functions from leoGlobals" section > in codewise.py and have codewise import leo.core.leoGlobals, or maybe a > copy of same. It's surprisingly inconvenient to have two copies of the > trace function in leoPy.leo. Of course, it would be possible to define > codewise.py in codewise.leo, and perhaps that is the better way. > > Again, I welcome your comments. > > Edward > > P.S. I have identified the nitty-gritty problem that pylint solves and that > clearly is the key to static type checking. I've created a "laboratory" to > study and simplify that code. I expect to spend a week or two more on this > phase of the static type checking project, and then, regardless of result, > it will be time to turn back to Leo for at least a full month. > > EKR > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
