On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote: > 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.
I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints "$[-0]" Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
