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 >> 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 concerns. 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
