On Sun, Jun 04, 2006 at 12:50:19AM +0000, Mikhael Goikhman wrote: > I think the ultimate solution is explained in file doc/todo-vars. > Among other things, it says that we only have variables in format $[], > all one letter variables are deprecated, and that a user may request > not to quote a value or choose from several quoting styles. > > However, we should decide about the default behaviour of variables > (when no explicit filters are specified). > > All variables with integer value like $[w.x] or fixed string value like > $[version.num] should not be quoted by default. > > All window name related variables should be qingle-quoted by default. > There is no question here, because names are really arbitrary. > > However, it is not clear about other less-arbitrary strings. I.e. should > $. be quoted? Currently it is quoted, but there is almost no chance > someone has quote characters in fvwm directories. On the other hand, > spaces are a bit more likely, so quoting here has pluses (less to type) > and minuses (may be surprised). > > Should $[w.iconfile] and $[w.miniiconfile] be quoted by default?
I don't know. > And finally, should $[ENV_VAR] like $[PATH] be quoted by default? Hm. > I see pros and cons to do this. Most of variable values (even $PATH) has > an expected value, so a user may guess about a proper quoting on his own. > On the other hand, the consistent solution would be to always quote any > string var. Hm, isn't the right way to fix this mess to rewrite the parser from scratch? I have the impression that we're trying to solve problems that are caused bay the flawed design. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature