>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> But not the real reason! The intention behind using std::map was
Lars> to get only unique command sequences (strings), a std::map gives
Lars> that for free. I did not think about the order issue then.
OK. However, there is already code in kbmap.C which checks that.
Lars> The bindings map does not mean to stay | around forever.
Lars> s/mean/need ?
Almost. it was s/does not mean/is not meant/
Lars> the global variable. by having it stay forever we can easily
Lars> dump all keybindings to a file.
But you do not put the bindings read from the bind files in this map.
And dumping is probably better done from toplevel_keymap. As it is,
you have two data structures in memory which hold the same information
(plus the hard-coded part of lyxrc, of course). It does not make much
sense...
Lars> | Lars> | - this adds some ugliness in lyx_main.C, that I'd
Lars> rather see | Lars> hidden in | lyxrc or keymaps. | | Lars> What
Lars> where? Some of this is historical baggage. The problem is |
Lars> Lars> the global vairables. | | I was referring to the loop
Lars> doing the actual bindings in LyX::LyX.
Lars> it is there because of the global variable toplevel_keymap.
You mean you plan to eventually remove this global variable?
Otherwise, why not access it from lyxrc.C? (as is already done, btw).
Lars> I never got eny real explanation for that. So you think we
Lars> should have user-definable dead keys. To me that does not make
Lars> sense. (i.e. redefine dead_acute)
No, I think we should have a way to obtain the _default_ X deadkeys,
meaning not redefining anything. Then the deadkeys will be handled by
the code which is already in LyXLookup (it's like the compose key). It
does not seem so outlandish that some people would like their dead keys to
work the same way in emacs and LyX? LyX should not be too obstructive, IMO.
Lars> Anyway all the variables in LyXRc should be moved to the private
Lars> section and accessor functions should be created, that would
Lars> solve your pimpl proplem too.
I do not see the use of doing that. According to
http://www.peerdirect.com/resources/gotw024a.html
only private functions/memeber should go there. What the point of
accessing lyxrc.printer() instead of lyxrc.printer? LyXRC is almost a
pure struct, after all.
JMarc
