On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: > On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] > >>Not true. With 'is_single_arg' true 'upper' will always be -1, so no other > >>parse-function will be called on the string. > > > >Then, why do you not write > > > > if (is_single_arg) > > ... > > *else* if (upper >= 0) > > ... > > > >? > > > > Probably because I didn't think of it as I added is_single_arg later to > deal with the fact that $0 should be the same as $[0]. > > >-- > > > >Hm, now that I think about it, the new functionality deviates from > >the way the old $0 ... worked in important ways which should be > >fixed: > > > >* A range of args like $[0-1] is expanded to the original text, > > not the unquoted form. > > > > I.e. in 'foo "a0" "a1" "a2"' > > > > $[0-1] is expanded to '"a0" "a1"' but should be expanded to > > 'a0 a1'. > > Do we really want that? It prevents passing arguments on to another > function. The way it is now (quote-persistent) is as $* has worked, and is > essensial for pasing multiple parameters on to another function without > risking that they split into more parameters than intended. I believe that > the current way is a good default until the variable quote system has been > implemented.
Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '"0"' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] > >* According to the man page, things like $[*] or $[3-] are > > removed from the command line if there are no arguments. This > > is wrong as it prevents that the string '$[*]' is passed to > > another command. These variable should not be treated > > specially. Currently, not even $[0] is identical to $0. > > > > The old variables also work in this way, so it's only trying to mimic the > old behaviour. All my tests make $[0] identical to $0. In what way are > they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. > >* The code is written too complicated too understand easily (as > > you can see from the fact that I only understood about 50% of > > it), and it's nested too deep. > > The deepest nestings are in the actual parsing of the parameters, and > that's hard to do without the nesting. Regarding the actual parameter > extraction I treid to write useful comments to tell what's going on and > why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
