Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
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.)
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
Thomas Adam 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
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
On Tue, Aug 26, 2014 at 03:20:09PM -0400, Dan Espen wrote: > Thomas Adam writes: > 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. Probably because nobody uses dynamic menus much. When fvwm reads a file or PipeRead input, it does not do anything in between, but input from modules cound trigger that. Anyway, it would be nice to have a clean scripting engine that can handle this correctly. You'd just have to store a separate '+' context for each source from which fvwm reads commands. > 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". Good idea. We should write that down somewhere. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
Just pushed a new version of the Abnf. On Tue, Aug 26, 2014 at 10:10:57PM +0100, Dominik Vogt wrote: > On Tue, Aug 26, 2014 at 03:20:09PM -0400, Dan Espen wrote: > > Thomas Adam writes: > > 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. > > Probably because nobody uses dynamic menus much. When fvwm reads > a file or PipeRead input, it does not do anything in between, but > input from modules cound trigger that. Anyway, it would be nice > to have a clean scripting engine that can handle this correctly. > You'd just have to store a separate '+' context for each source > from which fvwm reads commands. > > > 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". > > Good idea. We should write that down somewhere. Thomas, could you put this information somewhere? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Historical Parsing (twm onwards) [WAS: Re: REWRITE: Parsing]
On Tue, Sep 02, 2014 at 10:51:05PM +0100, Dominik Vogt wrote:
> Just pushed a new version of the Abnf.
>
> On Tue, Aug 26, 2014 at 10:10:57PM +0100, Dominik Vogt wrote:
> > On Tue, Aug 26, 2014 at 03:20:09PM -0400, Dan Espen wrote:
> > > Thomas Adam writes:
> > > 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.
> >
> > Probably because nobody uses dynamic menus much. When fvwm reads
> > a file or PipeRead input, it does not do anything in between, but
> > input from modules cound trigger that. Anyway, it would be nice
> > to have a clean scripting engine that can handle this correctly.
> > You'd just have to store a separate '+' context for each source
> > from which fvwm reads commands.
> >
> > > 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".
> >
> > Good idea. We should write that down somewhere.
>
> Thomas, could you put this information somewhere?
Done. It's in the TODO for now.
-- 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.)
