On Jan 30, 8:16 pm, "Edward K. Ream" <[email protected]> wrote:
> As expected, c.hash() is used *only* to create a "weak" link between a
> commander C created during a the prepass of a local file and *another*
> commander C2 created *later* during the second and final read of the local
> file.
> Happily, there is no need for a weak link: it is possible to create a
> "strong" link to the existing commander (or c.config).
I was completely mistaken. In fact, c.hash() solves a hard problem,
namely that Leo reads each "local" (non-setting) .leo file twice.
First, Leo reads *all* the local .leo files to discover their
settings. Next, Leo rereads the local .leo files "for real". For
example, if I invoke Leo to read a.leo, b.leo and c.leo, Leo will read
the following files, in this order::
leoSettings.leo
myLeoSettings.leo
a.leo (pass 1)
b.leo (pass 1)
c.leo (pass 1)
a.leo (pass 2)
b.leo (pass 2)
c.leo (pass 2)
Leo reads local .leo files twice in order to determine which settings
to use *during the second read*. In particular, Leo reads settings in
order to determine which *plugins* to enable for each file.
The Problem
-----------------
During pass 2 Leo must somehow get links to the commanders (and
c.config objects) created during pass 1.
c.hash() is the way that Leo does this. For each commander c created
in pass 1, g.app.config localOptionsDict.get(c.hash()) contains a
settings dict. g.app.config.get uses this dict to get the proper
dicts to search.
Shortcuts are handled separately, and almost certainly incorrectly,
which is probably why Viktor is having problems. Indeed, at present
Leo remembers only a *single* shortcuts dict. Depending on which
shortcuts are defined where, this could cause the vast majority of
shortcuts to disappear. Sorry about that, Viktor.
Possible solutions
------------------------
1. The quickest solution will be to enhance c.hash() so that it always
delivers a value sufficient to uniquely identify all loaded .leo
files. As Terry suggests, having c.hash() return an absolute path
will probably suffice. As implied above, a similar solution must be
used so that all shortcuts dictionaries are handled properly.
2. Another possible solution would be to read the a.leo, b.leo and
c.leo files only once. This might simplify the code, and speed up
Leo, but it would have the possibly serious drawback of redefining
what options are in effect while a .leo file is loading. This seems
like a risky approach. I strongly suspect the Kent would point out
problems, and such problems might require a reversion of the code.
Conclusions
----------------
First, Leo must, once again, correctly associate shortcuts
dictionaries with each .leo file. The only quick way to do this will
be to use c.hash() to access shortcuts dicts just like for the rest of
Leo's options. BTW, I'll want to ensure that the value of c.hash()
remains constant for each .leo file. I'm not even sure that c.hash()
is always the key into localOptionsDict.
Once Viktor can use the trunk again I'll start looking for other
solutions.
Edward
--
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.
