On Mon, May 21, 2001 at 02:50:45PM +0000, Mikhael Goikhman wrote: > 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.
I'm rather reluctant to open this can of worms again this close to 2.4. The problems you mention are not nice, but everything works as it used to right now. I already tried to fix some of this, but was not able to do so without breaking backwards compatibility. May this be a candidate for the ominous 3.0 release? I'd really like to throw away the whole parsing stuff and write it from scratch in a clean, well designed way. Of course that will break a lot of config files :-/ Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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]
