On Mon, Sep 26, 2016 at 07:50:51PM -0400, Donald R Laster Jr wrote: > > As I read the comments related to the configuration file parsing maybe the > initial focus should be on unifying the parsing code itself into a single > common set of functions or library package first. As I understand it, from > the reading the posts on this subject, many of the modules have their own
Modules don't change as part of this; separate problem. > So, as a 20+ plus year user of fvwm, who has been doing development for > more than 30 years, I would say the first step should be unify the parsing > code in FVWM. I use a fairly simple and straight forward configuration > for FVWM. Then look at ways to improvement the configuration file system > itself. I completely disagree there. Just that work alone means ripping up a lot of the internals to put back in-place something which doesn't address the changes I'm trying to do---namely unify the structure, and for that to happen, I'm convinced that the syntax also should change, and that's a side-effect, but a nice one. > The approach could be the 2.6.x releases be maintenance of "normal" > issues. And then the primary change for 2.7.x releases would be a unified > configuration file parsing system. I would recommend 2.7.x since from the > posts unifying the parsing code appears to be a potential complex > undertaking. Then later 2.7.x releases could support some early desirable > configuration file changes. Or once the 2.7.x parsing code is stable the > configuration file improvements could be introduced in later 2.7.x > releases, or 2.8.x could have improved configuration files. No thank you. I said long ago that there wouldn't be development happening like that again. We roll forward, and that's it. Furthermore, although your idea might work on a larger project---and more importantly---with more developers and people looking at the code, this proposal just isn't going to fly. -- Thomas Adam
