Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "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...
if we change the map to a vector and allow dublicate entries we will
be able to dump the excact same bindings as the user sees... (what a
weird sentence)
| 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.
Do as you wish.
I have only seen this issue when it comes to people that are using
kbmaps to circumvent the X keyhandling.
| 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.
You have not read enough of the GotW's... all variables should be
private is a mantra that is used quite often.
pimpl's do not work very well with public variables.
I think we should (as Asger has been hinting about earlier) do
something like:
template<class T>
class Variable {
public:
...
fromString(string const &);
string toString() const;
void setVal(T const &);
T const & val() const;
private:
...
};
and have a map of
map<string, Variable> AllVariables;
or something similar to this.
Then it would be very easy to have a generic "set-variable" or
"variable-set" lyxfunc to control all variables.
"variable-new" to create new variables.
"variable-describe"
etc...
Let's look at this in 1.1.6cvs.
Lgb
