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?
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
