On 09 Aug 2001 17:35:57 +0200, Dominik Vogt wrote: > > I'd rather rewrite the syntax 20 commands than extend the command > parser in such a way. Currently it is *the* worst piece of fvwm > code: not extensible, hard to understand, undpredictable, buggy.
I am not sure why do you think so. I see no reasons. It is actually not hard to understand if you understood the original smaller patch. Granted, I didn't tested it fully, only maybe 5-6 cases, But if you don't use the new stuff (command Otherwise or last status $?) there should not be any reduction in stability. This may wait for 2.5.0. > You are right: it can only work inside complex functions and "Read" > files and fail from modules and the command line. I guess then my > proposal is still the most sound one: easy to implement, the > patches are limited to a single file, helps with the most basic > needs some users have and does not encourage difficult to > implement enhancement requests. In my eyes, we can only think > about scripting support in the command parser if we are prepared > to throw away the whole code in functions.c and write it from > scratch - which explicitly means that the most central part of > fvwm becomes incompatible to older versions. Concurrent command execution is already broken within "+" command. This is an old problem, which probably can be solved if we store all "global" data last_* separately for every module pipe. Will this be a solution? Dominik, you once said that a lot of harm was done by many small patches each implementing its own inconsistent syntax. The enhancement you suggest is powerful, of course, you may write a whole if-else program in one line using nested conditions. But I don't feel this is a good syntax to introduce. I would not introduce any new syntax as radical as this without thinking about consistency with other command syntaxes. The solution that does not introduce any new syntax, but solves more than one problem is more preferable to me. After 2.5.0 we may think and change syntax. Anyway, I have no any willing to force my solution without your agreement. 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]
