Thomas Adam <> writes:

> On Mon, 19 Sep 2016 at 12:57 Ron Tapia <> wrote:
>> What are the
>> shortcomings of the current configuration format that the new format
>> addresses?
> 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.

Dan Espen

Reply via email to