The current command parsing is done in this order:
1) Handling the module command (if starting with '*')
2) Getting the first word (command name)
3) Expanding the first word and the entire command separately
4) Handling the internal command
This leads to several problems, like:
* The command starting with '*' is not a subject for parameter expansion,
thus making it impossible to construct module commands or have generic
module templates (without an overhead of forking using PipeRead echo)
* In module commands extended variables like $[fg.cs1] are not
expanded, sometimes making it hard to have functional module configs
* Calling function named "echo twice" does not work, although calling
function named "print twice" works. This just shows how bad is the
existing parsing order.
The problems are real, for example a sample in FAQ 7.13 does not work now.
I am not sure why it worked at all (2 bugs eliminate each other?).
Currently I am learning now how hard will be to implement a more correct
order without breaking anything:
1) Expanding the entire command
2) Handling the module command (if starting with '*')
2) Getting the first word (command name)
3) Handling the internal command
This would fix all 3 problems above together with more inconsistencies,
say, a leading '-' (meaning don't expand) would work for all commands.
Of course, for backward compatibility single-letter variables in module
commands should not be expanded (this is unfortunate, but needed, since
FvwmButtons and FvwmForm expect this). However $[] variables is a new
invention and there is no reason not to expand them in module commands.
Does anyone see any problem if $0 to $9 are expanded in module commands
inside functions? I can't think of any except of really exotic examples,
in which the raw '$0' could be escaped like in any other place - '$$0'.
BTW, I think it is not late yet to reduce expanding collisions and use '%'
instead of '$' in the new FvwmButtons constructions: %fg, %right, %width.
Or a less conflicting syntax $(fg), like the one already used in FvwmForm.
This is not the best time for this reworking, but the existing command
parsing problems should be solved (at least FAQ 7.13 sample should work).
As usual I will not change anything without a thorough testing first.
Any comments are welcome.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
