Re: FVWM: [Draft] New Configuration Format

[gi1242+fvwm]

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

[t.funk]

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

[Stephen Dennison]

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

[Thomas Adam]

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

[gi1242+fvwm]

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

[Thomas Adam]

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

[gi1242+fvwm]

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

[elliot s]

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

[Dan Espen]

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

[Thomas Adam]

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

[Ron Tapia]

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 <horsley1...@gmail.com>
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

[Tom Horsley]

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 :-).