Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> handling, and | saw several things: | | - the bindings are not
| Lars> saved in a map. Lars did you do this just for
|
| Lars> s/not/now?
|
| Indeed.
|
| Lars> O(log n) instead of O(n).
|
| That's a good reason.
But not the real reason! The intention behind using std::map was to
get only unique command sequences (strings), a std::map gives that for
free. I did not think about the order issue then.
| Lars> Ok this can be fixed by providing a more clever comparison
| Lars> operator (functor). Was this any different earlier? (before
| Lars> kbmap rewrite)
|
| What worries me is that you do not know in which order the binding
| will be done (am I wrong?). Why not have a simple queue of
| (kmap,function)?
the uniqness problem. with some additional code the std::map can be
replaced with a vector or a deque.
| Lars> | - the bindings member creates duplicates templates, for no
| Lars> apparent | gain (and I do not see how to `pimpl' it cleanly)
|
| Lars> What template? What do you want to pimpl? kb_keymap?
|
| The map<string,int> in lyxrc. lyxrc.h is included in a lot of
| places and most of these places could not care less of this bindings
| stuff. In fact, I do not understand why the bindings map (assuming it
| actually is useful) is not local to defaultKeyBindings(), which could
| do the bind loop by itself. The bindings map does not mean to stay
| around forever.
s/mean/need ?
the global variable.
by having it stay forever we can easily dump all keybindings to a
file.
| Lars> | - this adds some ugliness in lyx_main.C, that I'd rather see
| Lars> hidden in | lyxrc or keymaps.
|
| Lars> What where? Some of this is historical baggage. The problem is
| Lars> the global vairables.
|
| I was referring to the loop doing the actual bindings in LyX::LyX.
it is there because of the global variable toplevel_keymap.
| Lars> | - you do the bindings as early as possible. Is there a reason
| Lars> for | that? Can I move at least the deadkey bindings until after
| Lars> lyxrc has | been read?
|
| Lars> Why? We want the hardcoded bindings to go in first.
|
| I'd like to render the bindings of X deadkeys to LyX deadkeys optional
| (remember the messages from a while ago). This means that I have to
| defer this part of the bindings until after lyxrc has been read.
I never got eny real explanation for that.
So you think we should have user-definable dead keys. To me that does
not make sense. (i.e. redefine dead_acute)
| Another soltion would be to do all the default bindings after lyxrc
| has been read, but only for keys that have not yet been bound.
nah.
Anyway all the variables in LyXRc should be moved to the private
section and accessor functions should be created, that would
solve your pimpl proplem too.
Lgb
