Thomas Adam <tho...@fvwm.org> writes:
> On Mon, 19 Sep 2016 at 12:57 Ron Tapia <rd...@psu.edu> wrote:
>> What are the
>> shortcomings of the current configuration format that the new format
> Have another read of that document, Ron. FVWM is completely governed
> by how it reads in commands, and hence at the moment, each command is
> responsible for parsing its values. There's been twenty years of this
> idea; organically growing out of control. Adding or even changing
> existing options to commands is a nightmare; there's no state being
> kept between commands (which would be good), and hence there's a lot
> of the same sorts of information being gathered separately, leading to
> a lot of duplication at the code-level.
Actually, there is state kept between commands, or the "+" operator
and the backslash for continuation would never work.
(If that is what you were trying to say.)
My comment is that the new commands are unreadable.
Also, I do not want to change my existing config file.
In the past we never changed the config file unless we could
supply a conversion script to make the transition invisible to users.
None of the proposed changes show any new functionality.
Years and years ago we had a proposal that Fvwm change to using
Scheme as it's command language. I can see how that would add
functionality. At the time I was against that mainly for bloat
The current Fvwm command structure is designed around readability.
The context switches being a necessary exception.
We currently do this:
Mouse 2 W SM Move 100 0
Key Left A C Scroll -100 0
We could allow:
Mouse 2 Window Shift+Meta Move 100 0
Key Left All Ctrl Scroll -100 0
The concept of a "bind" command is interesting.
But it feels like we'd be bringing implementation
details into the command language. Not always a good thing.