Re: [Draft] New Configuration Format
Hallo, I have a very fancy setup with nested function definitions. Parts of my ".fvwm2rc" look like this: AddToFunc BCopy I (...) + I Pick AddToFunc $0 I WindowId $[w.id] (State 2) [*] $[1-] + I + I Next (!State 4) Move + I (...) So, I dynamically define complex functions during user operation rather than during configuration read-in (and delete them again later). This makes it possible to have functions specific for one certain window, iden- tified by its window ID. I do the same with dynamical (window-specific) decors. Whatever new syntax you will decide for - I would be happy not to lose this possibility. Best regards Werner P.S. Oh, and concerning the discussion about function continuation by '\' before end-of-line or '+' after beginning-of-line: Why not offer both and let the user choose?
Re: FVWM: [Draft] New Configuration Format
One thing I wouldn't mind added is "here documents". I use FvwmPerl quite a bit and my config is full of things like + I SendToModule perlwops eval \ my ($NEWX, $WIN) = (0, undef); \ foreach $WIN (@b) { \ $NEWX = $WIN->{x}+$WIN->{width} \ ... (10 more lines) It might make things more readable if I could do + I SendToModule perlwops eval <<< "EOF" blah EOF instead without having to worry about the backslashes. GI -- TOP 10 NEW FEATURES OF THE NEXT VERSION OF WINDOWS 2. Don't bother taking the Mac icon off the start-up screen this time.
Fwd: Re: FVWM: [Draft] New Configuration Format
Hi, Dan Espen wrote: Thomas Adam writes: On Mon, Sep 19, 2016 at 04:44:25PM -0400, Dan Espen wrote: Yes. I tried to bring up the subject of readability. OK. Specifically? New vs. Old: Colorset -n1 -b red -f red Colorset 1 bg red, fg red One is easy to read, write, and remember. The other isn't. I'm not seeing the advantage. We could use '- -' to extend the restricted possibilities : Colorset -n1 - -bg red - -fg red Best Thomas
Re: FVWM: [Draft] New Configuration Format
> > You can find the draft at: > https://github.com/fvwmorg/fvwm/blob/ta/new-config-format/ > docs/NEW-CONFIG.md > > I read through the draft a bit, below are my questions/comments. For parsing compatibility, perhaps a special command, comment, or token to indicate which format is being used so that FVWM (and humans) need not guess? Will there be a way to have fvwm yield it's current configuration while it's running? If you're going through the effort of redoing the configuration parser, this seems like a great time to do this and it would be a huge motivator for using the new syntax. I'm trying to make sense of the use of comma in the -w option. It's not very mini-CLI of it. Why not allow the -w option to be specified more than once and in each case it could make use of a different prefix to the value. For example, (if I wanted urxvt to be red and xterm to be blue): Style -w r:x-terminal-emulator -w c:URxvt Colorset 1 Style -w r:x-terminal-emulator -w c:xterm Colorset 2 Though, in retrospect, perhaps duplicating the option and having a special prefix in the value probably isn't very CLI either. Do you plan support actual string names of colorsets or are you just sort of shoehorning the -n name for the number? The values passed to -t in those focus commands has me confused. Above, something else that had -t used the format screen:desk.page but this doesn't appear to apply to the Focus command. Could you more explicitly describe this?
Re: FVWM: [Draft] New Configuration Format
On Mon, Sep 19, 2016 at 03:50:31PM -0400, gi1242+f...@gmail.com wrote: > On Mon, Sep 19, 2016 at 08:45:12PM +0100, Thomas Adam wrote: > > > Yes, yes, conversion script(s). There'll be something to ensure > > people can start from a known point and potentially not have to learn > > anything new as well if they don't want to. Ignorance through > > continuity has benefits... > > Thanks a TON. Don't misunderstand me, some means of going from old -> new is important, and will be done. I've always done that previously, and now isn't a time to stop. It's just not something I want a potential discussion on to overshadow other points. -- Thomas Adam
Re: FVWM: [Draft] New Configuration Format
On Mon, Sep 19, 2016 at 08:45:12PM +0100, Thomas Adam wrote: > Yes, yes, conversion script(s). There'll be something to ensure > people can start from a known point and potentially not have to learn > anything new as well if they don't want to. Ignorance through > continuity has benefits... Thanks a TON. GI -- 'Stress' -- The confusion created when ones mind overrides the body's basic desire to choke the living crap out of some butthead who desperately needs it.
Re: FVWM: [Draft] New Configuration Format
On Mon, Sep 19, 2016 at 03:16:46PM -0400, gi1242+f...@gmail.com wrote: > On Mon, Sep 19, 2016 at 11:05:23AM -0700, elliot s wrote: > > > If a conversion script can convert the current rc file to a code > > friendly format, can a front end parser do that instead, so that we > > keep the current user friendly format? > > Usually conversion scripts aren't perfect, so I don't know how workable > this is. > > But let me also add my two cents and desperately plead for backward > compatibility. Or at least a conversion script that is pretty pretty > good. Yes, yes, conversion script(s). There'll be something to ensure people can start from a known point and potentially not have to learn anything new as well if they don't want to. Ignorance through continuity has benefits... Can we move on to some other point of discussion now? -- Thomas Adam
Re: FVWM: [Draft] New Configuration Format
On Mon, Sep 19, 2016 at 11:05:23AM -0700, elliot s wrote: > If a conversion script can convert the current rc file to a code > friendly format, can a front end parser do that instead, so that we > keep the current user friendly format? Usually conversion scripts aren't perfect, so I don't know how workable this is. But let me also add my two cents and desperately plead for backward compatibility. Or at least a conversion script that is pretty pretty good. When Python decided to break backward compatibility in version 3, they completely fragmented the user base. Despite them supplying a conversion script! It has been 8 years now, and adoption of python 3 is far from universal. Please don't follow suite and fragment the Fvwm user base as well. Debian popularity contest shows that the Fvwm user base now is about 1500, just a hair above what it was in 2008: https://qa.debian.org/popcon.php?package=fvwm So Fvwm isn't gaining too many new users. If backward incompatible changes fragment the current user base even more I'll be a little worried. Thanks, GI -- He often broke into song because he couldn't find the key.
Re: FVWM: [Draft] New Configuration Format
If a conversion script can convert the current rc file to a code friendly format, can a front end parser do that instead, so that we keep the current user friendly format?
Re: FVWM: [Draft] New Configuration Format
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 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 LeftA C Scroll -100 0 We could allow: Mouse 2 Window Shift+Meta Move 100 0 Key LeftAll CtrlScroll -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
Re: FVWM: [Draft] New Configuration Format
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. Changing the format is a great way of getting a clean break, and being able to rationalise the commands we have now, and need; moving functionality into other commands in an extensible way, which will also reduce the code complexity somewhat. You can't easily do this with the format we have now. Dominik and I have given this a lot of thought[0] and to my mind, trying to keep with what we have is a lot of work, more so than changing it. None of this precludes what we have now in terms of preprocessing, and having other things produce a configuration file in a format FVWM can read in. Indeed, there will be conversion scripts to handle the transition. So this is coming, albeit slowly, and right now what there is are just my ideas with the beginnings of an implementation to see what that looks like. People are welcome to comment on functionality, etc., with other suggestions. For the rest of you saying: "It's been that way for the last X years" need to wake up and realise that I will be making little changes as time goes on. FVWM has laid stagnant for a long time, and it's about time someone stepped up to the plate and helped to modernise/improve things a little. It's boring work, it's certainly not feature development, but if this work isn't started now, or thought about, you won't see much more happening with FVWM since all of these organically-grown problems need solving first. That's why we're in the situation we are now---no one has wanted to do it, and what we have is one big mess. So wake up, people. A change is on the horizon. It won't happen overnight, but it does need to happen. -- Thomas Adam [0] https://github.com/fvwmorg/fvwm/blob/master/docs/PARSING.md
Re: FVWM: [Draft] New Configuration Format
Hi, I have to agree. Part of the reason is that there is not a lot of FVWM development is that it does what it does very well and has not needed a lot of change. I know that I've heard people asking for support for 3D effects, but I've never heard a complaint about the configuration format. What are the shortcomings of the current configuration format that the new format addresses? Cheers, Ron -- If C++ is your only tool, all problems look like your thumb. On Mon, 19 Sep 2016, Tom Horsley wrote: Date: Mon, 19 Sep 2016 07:48:49 -0400 From: Tom Horsley Cc: f...@fvwm.org, fvwm-workers@fvwm.org Subject: Re: FVWM: [Draft] New Configuration Format On Mon, 19 Sep 2016 12:38:04 +0200 Bert Geens wrote: Hello fellow Fvwm users, Thomas has started working on a draft for a new configuration format that should fix some of the shortcomings of the current one. There are no shortcomings in the current format :-). It has the overwhelmingly important attribute of not frigging changing out from under me every dadgum release because someone thinks it is too old and needs to change. I use fvwm because it keeps working the same way all the time when everything else on linux is cursed with change for the sake of change. Don't do it :-).
Re: FVWM: [Draft] New Configuration Format
On Mon, 19 Sep 2016 12:38:04 +0200 Bert Geens wrote: > Hello fellow Fvwm users, > > Thomas has started working on a draft for a new configuration format > that should fix some of the shortcomings of the current one. There are no shortcomings in the current format :-). It has the overwhelmingly important attribute of not frigging changing out from under me every dadgum release because someone thinks it is too old and needs to change. I use fvwm because it keeps working the same way all the time when everything else on linux is cursed with change for the sake of change. Don't do it :-).
[Draft] New Configuration Format
Hello fellow Fvwm users, Thomas has started working on a draft for a new configuration format that should fix some of the shortcomings of the current one. You can find the draft at: https://github.com/fvwmorg/fvwm/blob/ta/new-config-format/docs/NEW-CONFIG.md Be aware that this is still very early stages so subject to (major) changes. Kind regards, Bert Geens