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 tho...@fvwm.org 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 tho...@fvwm.org 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.)
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 tho...@fvwm.org 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 tho...@fvwm.org 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
