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. > 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 view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/9cdshRVkqM4J. 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.
