Thomas Adam <[email protected]> writes: > On Tue, Aug 26, 2014 at 07:32:17PM +0100, Dominik Vogt wrote: >> > > Another example are function definitions: >> > > >> > > AddToFunc TeddyBear "I" Echo "xteddy" >> > > AddToFunc "TeddyBear" >> > > + "C" Exec exec xteddy >> > > + M Nop >> >> This is actually a terrible piece of the fvwm syntax: Function and >> menu definitions are not atomic. If you write a function definition >> using FvwmConsole, the meaning of the '+' might change between lines: >> For example, if a function is triggered that uses PipeRead to >> generate a menu definition on the fly while you type into FvwmConsole, >> the next '+' might no longer add to the function but to the menu >> instead. And let's not talk about functions that generate functions >> that generate functions. > > Oh absolutely---I'm amazed we've not encountered bugs with regards to > this---clearly over the years the developers have done something right. > Or maybe it's that, and no one's used this in the weird and wonderful > ways that would break things. > > Since we're on this subject, I'm curious about some of fvwm's history. > fvwm (1.x) had what I'd call "block" level constructs, so for > example: > > Function "Resize-or-Raise" > Resize "Motion" > Raise "Motion" > Raise "Click" > RaiseLower "DoubleClick" > EndFunction > > This is at odds from twm which uses constructs like: > > Function "move-or-iconify" { > f.move f.deltastop f.iconify > } > > Although the intent is the same; and from what I can tell of fvwm 1.X's > code having just quickly eye-balled it, nested function definitions > wasn't possible. > > I wonder when the "+" command was introduced into fvwm, and did it > always have a triple-meaning of menu/function/decor? Or did that get > extended over time?
I might take the blame for other mis-designed things, but as far as I remember, that goes way back. I think the issue was those pretty long commands "AddToFunc", etc. But the "+" sign is just broken. On the other hand, I've never seen it cause a real problem. I think Fvwm just scoops up commands so fast that it's unlikely that there will be a conflict. A warning in the man page might be in order. It would be nice if Fvwm reported where it found an error (line 40 .fvwm/config) which would make the parser aware of where commands are coming from and provide a way to fix this. Of course sometimes it would be "FvwmAnimate PID 1234, 20th command". -- Dan Espen
