On Thu, 13 Jul 2006, 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.
$* has always worked they way it works as well. I for sure have some
functions that rely on passing arguments to other functions, so changing
the behaviour of $* would break my config. Also reading the todo-vars file
it states that $[<number>] should be unquoted for backwardscompability.
The $[<range>] can be treated differently as that is a new feature. I see
use for both the 'raw' style and the unquoted style, but as I understand
the todo it really should be single-quoted as they are niether $[<number>]
not $[<range>], which are the only exceptions to that rule listed.
Regarding the dequoting of the positional parameters I belive the best
thing would be to make a function to unquote an entire string. I'm not
sure how optimized it is to peek every token just to get rid of the
quotings. Also the most flexible code for the argument expansion would be
keeping the raw string as long as possible, and then dequote it and
possible requote it depending on filter-selection.
Maybe the best thing is to remove the $[<range>] alltogether until the
filter-system is ready to not add another exception to how things work.
I'd really like to hear Mikhael's opinion on this.
[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'll take a look at the code more later. Currenlty I've only looked at the
diff to get some idea of what you are doing.
/Viktor
