Re: FVWM: [Draft] New Configuration Format

[Donald R Laster Jr]

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 parsing 
code.  Eliminating this redundancy would be a good thing for future 
improvements and maintainability.  And doing this first would be less likely to 
introduce unexpected problems.

  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.

  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.

Don

Dan Espen wrote on 09/26/2016 09:33 AM:
> Ethan Raynor  writes:
> 
>> On Mon, Sep 26, 2016 at 12:13 AM, Dan Espen  wrote:
>>> Sounds to me like you are not subscribed to fvwm-workers.
>>> If you care about things like the repository, you should subscribe.
>>
>> ok - I will do this. How busy is the list?
> 
> Not very, but when the conversation turns to development issues
> only, fvwm-workers@ is sometimes used without fvwm@ being included.
> 
>>> Read the various TODO files.
>>
>> The only one I can see is this one -
>> https://github.com/fvwmorg/fvwm/blob/master/TODO.md

> 
> The very fact that Thomas is publishing a write up instead of
> diving into changes tells me he's looking for these kinds of
> comments.
> 

Re: FVWM: [Draft] New Configuration Format

[Dan Espen]

Ethan Raynor  writes:

> On Mon, Sep 26, 2016 at 12:13 AM, Dan Espen  wrote:
>> Sounds to me like you are not subscribed to fvwm-workers.
>> If you care about things like the repository, you should subscribe.
>
> ok - I will do this. How busy is the list?

Not very, but when the conversation turns to development issues
only, fvwm-workers@ is sometimes used without fvwm@ being included.

>> Read the various TODO files.
>
> The only one I can see is this one -
> https://github.com/fvwmorg/fvwm/blob/master/TODO.md

That's the current file.
You would have to look in older releases to see the evolution.

> i confess to not completely understanding the rationale for some of
> the items there.

>From docs/old_info/TODO

  Please note that not everything on this list will be done, in
  particular the ones that end in '?' which are really just meant to be
  'think about this and perhaps investigate'.  But they are things that
  I didn't want to lose track of.  It may periodically get out of date
  too...

>> I'd like to see improvements in the way parsing is done
>> inside fvwm.  There is so much parsing code that does
>> the same basic thing.  A table driven approach would
>> be a big improvement.
>>
>> If the command syntax has to change to get there,
>> I'd like to understand why.
>
> well afaict the proposal is to rip up things more than that - why?

As I said, our two most productive developers saw the need.
I too remain unconvinced of the benefits.
That's why development is conducted in an open forum.

The very fact that Thomas is publishing a write up instead of
diving into changes tells me he's looking for these kinds of
comments.

-- 
Dan Espen

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Mon, Sep 26, 2016 at 12:13 AM, Dan Espen  wrote:
> Sounds to me like you are not subscribed to fvwm-workers.
> If you care about things like the repository, you should subscribe.

ok - I will do this. How busy is the list?

> Read the various TODO files.

The only one I can see is this one -
https://github.com/fvwmorg/fvwm/blob/master/TODO.md

i confess to not completely understanding the rationale for some of
the items there.

> I'd like to see improvements in the way parsing is done
> inside fvwm.  There is so much parsing code that does
> the same basic thing.  A table driven approach would
> be a big improvement.
>
> If the command syntax has to change to get there,
> I'd like to understand why.

well afaict the proposal is to rip up things more than that - why?

Ethan

Re: FVWM: [Draft] New Configuration Format

[Dan Espen]

Ethan Raynor  writes:

> On Sun, Sep 25, 2016 at 11:50 PM, Dan Espen  wrote:
>> Yes, a number of people wanted git.
>> No point in arguing against that.
>> It's accepted that git out does CVS in functionality.
>
> But I can't recall when on the fvwm lists the pros and cons of moving.
> I know that github is considered the place to be - but I've also had
> some nasty encounters with it when things go bad - and other places
> like bitbucket have greater resiliance  - not to mention guaranteed
> backups!!

Sounds to me like you are not subscribed to fvwm-workers.
If you care about things like the repository, you should subscribe.

>> You've ruined your point about the config change by bringing in
>> a bunch of irrelevant stuff.
>
> Not exactly, Dan. The point i'm putting across to thomas and others is
> the perception of the changes - they come out of no where with any
> warning. That can be a bad thing

Nope.

Read the various TODO files.
Major parser change has been on the list a long time.
In fact Thomas was not the major maintainer at the time.

I'd like to see improvements in the way parsing is done
inside fvwm.  There is so much parsing code that does
the same basic thing.  A table driven approach would
be a big improvement.

If the command syntax has to change to get there,
I'd like to understand why.

-- 
Dan Espen

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Sun, Sep 25, 2016 at 11:50 PM, Dan Espen  wrote:
> Yes, a number of people wanted git.
> No point in arguing against that.
> It's accepted that git out does CVS in functionality.

But I can't recall when on the fvwm lists the pros and cons of moving.
I know that github is considered the place to be - but I've also had
some nasty encounters with it when things go bad - and other places
like bitbucket have greater resiliance  - not to mention guaranteed
backups!!

> You've ruined your point about the config change by bringing in
> a bunch of irrelevant stuff.

Not exactly, Dan. The point i'm putting across to thomas and others is
the perception of the changes - they come out of no where with any
warning. That can be a bad thing

Ethan

Re: FVWM: [Draft] New Configuration Format

[Dan Espen]

Ethan Raynor  writes:

> On Fri, Sep 23, 2016 at 1:58 PM, Lucio Chiappetti
>  wrote:
>> On Fri, 23 Sep 2016, Thomas Adam wrote:
>>
>>> On Fri, Sep 23, 2016 at 12:42:14PM +0200, Lucio Chiappetti wrote:

 is <<< a perlism, or a typo for more customary << ?
>>>
>>>
>>> In shell, <<< is a here-string.
>>
>>
>> I wasn't aware of the distinction between here-documents and here-strings (I
>> had to check https://en.wikipedia.org/wiki/Here_document), I've always used
>> only the former.
>>
 Does this apply to ANY occurrences which in your new scheme will use the
 backslash like the old AddToFunc followed by lots of + I lines ?
>>>
>>>
>>> Yes.
>
> I think this is a mistake. I've read through the doc you've put out
> twice, and i cannot see any compelling reason to change things. For my
> purposes, the expressiveness of what's there now is an asset we should
> retain - look at your proposal...
>
> function -n myfunc < i:athing
> EOF
>
> what if myfunc didn't do 'athing' properly? how is that handled?
>
> i don't feel as though you're thinking about this properly.
>
> It's also a concern that we have seen:
>
> o fvwm stale for quite some time

Fvwm is stable, not stale. 

> o fvwm forked to mvwm (what happened there)?

A good thing that the name change hasn't occurred.

> o fvwm moved to github - why? no one asked for that

Yes, a number of people wanted git.
No point in arguing against that.
It's accepted that git out does CVS in functionality.

> o fvwm website redesigned - no one asked for that

The web site changed when we moved to github of necessity.
PHP wasn't available.

> If all these werent enough, now we've got a change of config to contend with?
>
> I am not pleased.

You've ruined your point about the config change by bringing in
a bunch of irrelevant stuff.

-- 
Dan Espen

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

On Fri, Sep 23, 2016 at 1:58 PM, Lucio Chiappetti
 wrote:
> On Fri, 23 Sep 2016, Thomas Adam wrote:
>
>> On Fri, Sep 23, 2016 at 12:42:14PM +0200, Lucio Chiappetti wrote:
>>>
>>> is <<< a perlism, or a typo for more customary << ?
>>
>>
>> In shell, <<< is a here-string.
>
>
> I wasn't aware of the distinction between here-documents and here-strings (I
> had to check https://en.wikipedia.org/wiki/Here_document), I've always used
> only the former.
>
>>> Does this apply to ANY occurrences which in your new scheme will use the
>>> backslash like the old AddToFunc followed by lots of + I lines ?
>>
>>
>> Yes.

I think this is a mistake. I've read through the doc you've put out
twice, and i cannot see any compelling reason to change things. For my
purposes, the expressiveness of what's there now is an asset we should
retain - look at your proposal...

function -n myfunc <

Re: FVWM: [Draft] New Configuration Format

[Ethan Raynor]

Hi,

I have been using fvwm for a while and I think that this idea of
changing the config format is ill thought out and silly. Why does this
need changing now after all these years? I can't see how you expect a
script to convert to this new format easily - its a very lofty goal.

Don't do this at all - go and do features or something people want.
Why do you always try and make these sweeping changes?

Ethan

On Mon, Sep 19, 2016 at 1:25 PM, Thomas Adam  wrote:
> 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

[Lucio Chiappetti]

On Fri, 23 Sep 2016, Thomas Adam wrote:


On Fri, Sep 23, 2016 at 12:42:14PM +0200, Lucio Chiappetti wrote:

is <<< a perlism, or a typo for more customary << ?


In shell, <<< is a here-string.


I wasn't aware of the distinction between here-documents and here-strings 
(I had to check https://en.wikipedia.org/wiki/Here_document), I've always 
used only the former.


Does this apply to ANY occurrences which in your new scheme will use 
the backslash like the old AddToFunc followed by lots of + I lines ?


Yes.


For me looks ok

--

Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html

Do not like Firefox >=29 ?  Get Pale Moon !  http://www.palemoon.org

Re: FVWM: [Draft] New Configuration Format

[Lucio Chiappetti]

On Fri, 23 Sep 2016, Thomas Adam wrote:

On Wed, Sep 21, 2016 at 09:26:08AM -0400, gi1242+f...@gmail.com wrote:



I use FvwmPerl quite a bit ...


Never used FvwmPerl nor perl, just a couple of FvwmScript, but I know here 
documents from shell scripting where I use them a lot.



+ I SendToModule perlwops eval <<< "EOF"
blah
EOF


is <<< a perlism, or a typo for more customary << ?



instead without having to worry about the backslashes.


I think this is reasonable; I'll add it to the document.  Thanks.


Does this apply to ANY occurrences which in your new scheme will use the 
backslash like the old AddToFunc followed by lots of + I lines ?


That would be rather nice, better than the backslashes.
Thanks

--

Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html

Do not like Firefox >=29 ?  Get Pale Moon !  http://www.palemoon.org

Re: FVWM: [Draft] New Configuration Format - Functions

[Thomas Adam]

On Fri, Sep 23, 2016 at 05:23:41AM -0400, Donald R Laster Jr wrote:
> 
> When it comes to functions the cleaner format might be to use a variant of
> the Bourne/Bash/"C" format such as  this:

I don't think so.  At best you're going to get a heredoc to slurp up multiple
lines.  The point here is that they're structured only in terms of the command
*responsible* for handling functions.

I don't want to turn the format into a scripting language; this isn't the
point---we *have* FvwmPerl and others which you can use.  I am not proposing
we augment or change the current "scripting" behaviour of FVWM either.

So no more language comparisons, please.

-- Thomas Adam

Re: FVWM: [Draft] New Configuration Format

[Thomas Adam]

On Wed, Sep 21, 2016 at 09:26:08AM -0400, gi1242+f...@gmail.com wrote:
> 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.

I think this is reasonable; I'll add it to the document.  Thanks.

-- Thomas Adam

Re: FVWM: [Draft] New Configuration Format - Functions

[Donald R Laster Jr]

When it comes to functions the cleaner format might be to use a variant of the 
Bourne/Bash/"C" format such as  this:

function name(arg1, arg2, ... argN)
{


   return(defaults to 0 if not specified)
}

White space would be irrelevant, whether tabs or spaces are used.  Actual 
desired white space would be in "" or '' sequences as programming languages 
require now.  Command on the same line could separated by ";" as most scripting 
and programming languages use.  Lines could be continued with "\" if desired.  
Variable would be local in scope unless the InfoStoreAdd reference method is 
used, i.e.

 InfoStoreAdd xtermopts "-sb -sl 2000 -aw -rw-j -ls -fn 7x14 -fb 
7x14bold"

and then referenced as done now:

 +  I exec xterm  $[infostore.xtermopts] $[infostore.geo2]+0+0  &

with the sequence "$[ var.name ]" sequence.  And the sequence "{ }" would 
identify the start and ending of the function's body.  The "function" keyword 
could be "AddFunction".  An alternate format could be:

 AddFunction name(arg1, arg2, ... argN)

   

   return  (defaults to 0 if not specified)
 EndFunction

Where the keyword "AddFunction" defines the name of the function and list of 
argument references, and the keyword "EndFunction" specifies that the function 
end point.  Or even something like this where keywords are used to define 
things in different method:

 AddFunction name
 FunctionArg arg1
 FunctionArg arg2
 .
 .
 .
 FunctionArg argN
 BeginFunction


return  (defaults to 0 if not specified)
 EndFunction

The AddFunction keyword could even be extended to specify a program (i.e. 
perl,, php, bash, etc.) to execute the script - say using the format:

 AddFunction name execuute-by

>From my perspective the first and second formats make more sense.

  Keep in mind my .fvwm2 file is pretty simple and based upon the existing 
default.  I use a single 24x4 window paging environment.  I added my .fvwm2rc 
file as fvwm2rc for reference.  I did some cleanup formatting for the regular 
comments.

Don

John Wiggins wrote on 09/21/2016 11:31 PM:
> The python method has some serious defficiencies when applied to input files 
> like .fvwmrc2, i.e. white space you cannot see (space vs tab) matters and 
> cause read errors that drive you crazy…
> 
> IMO, the 
>   BlockB {
>   line1,
>   line2,
>   line3_and_white_space_doesNotMatter,
> So_This_isValid,
>   andSPACESORTABS_DO_NOT_MATTER}
> 
> 
>> BlockB {
>> line1,
>> line2,
>> line3,
>> line4
>> }
> 
>> On Sep 21, 2016, at 9:49 PM, elliot s  wrote:
>>
>> <<
>> BlockA \
>> line1, \
>> line2, \
>> line3, \
>> line4
>>
>> Is less visually appealing and can be more difficult locate errors than
>>
>> BlockB {
>> line1,
>> line2,
>> line3,
>> line4
>> }

>>
>> There's the python method of blockingusing indentation.  WYSIWYG
>> I was skeptical at first, but now i like it.
>>
>> if x:   # note the :
>> y=z
>>a=1
>>if n:
>>a=3
>>b=1
>>else:
>>b = 0
>>print a,b
>> print y
>>
> 
> 
#
#   
#
# .fvwm2rc
R00-00.06 #
#   
#
# 
=
 #
#   
#
# Purpose:  
#
#   
#
#   
#
# 
=
 #
#   
#
# Arguments:
#
#   
#
# This file is copied to a new user's FVWM_USERDIR by FvwmForm-Setup form.  
#
# This file contains the commands fvwm reads while starting.
#
#   
#
# 
=
 #
#   
#
# Programming Notes:

Re: FVWM: [Draft] New Configuration Format

[John Wiggins]

The python method has some serious defficiencies when applied to input files 
like .fvwmrc2, i.e. white space you cannot see (space vs tab) matters and cause 
read errors that drive you crazy…

IMO, the 
BlockB {
line1,
line2,
line3_and_white_space_doesNotMatter,
So_This_isValid,
andSPACESORTABS_DO_NOT_MATTER}


> BlockB {
> line1,
> line2,
> line3,
> line4
> }

> On Sep 21, 2016, at 9:49 PM, elliot s  wrote:
> 
> <<
> BlockA \
> line1, \
> line2, \
> line3, \
> line4
> 
> Is less visually appealing and can be more difficult locate errors than
> 
> BlockB {
> line1,
> line2,
> line3,
> line4
> }
>>> 
> 
> There's the python method of blockingusing indentation.  WYSIWYG
> I was skeptical at first, but now i like it.
> 
> if x:   # note the :
> y=z
>a=1
>if n:
>a=3
>b=1
>else:
>b = 0
>print a,b
> print y
> 

Re: FVWM: [Draft] New Configuration Format

[elliot s]

<<
BlockA \
 line1, \
 line2, \
 line3, \
 line4

 Is less visually appealing and can be more difficult locate errors than

 BlockB {
 line1,
 line2,
 line3,
 line4
 }
>>

There's the python method of blockingusing indentation.  WYSIWYG
I was skeptical at first, but now i like it.

if x:   # note the :
 y=z
a=1
if n:
a=3
b=1
else:
b = 0
print a,b
print y

Re: FVWM: [Draft] New Configuration Format

[lists-fvwm]

On Wed, Sep 21, 2016 at 11:37:41PM +0100, Thomas Adam wrote:
> On Wed, Sep 21, 2016 at 06:38:27PM -0400, lists-f...@useunix.net wrote:
> > Is it different as in it gets rid of the annoying '\' characters that
> > need to be at the end of every line. Unless you are saying that they
> > aren't necessary?
> 
> They're continuation markers.  Lots of programs honour those when reading in
> files, as does FVWM at present, so this isn't anything new, and the point of
> using them is to allow people to improve readability.
> 
> -- Thomas Adam
>

Understood.

In my experience they only serve to enhance readability when the
language processor doesn't handle processing a group of lines using
block delimiters.

BlockA \
line1, \
line2, \
line3, \
line4

Is less visually appealing and can be more difficult locate errors than

BlockB {
line1,
line2,
line3,
line4
}

Wayne

Re: FVWM: [Draft] New Configuration Format

[Thomas Adam]

On Wed, Sep 21, 2016 at 06:38:27PM -0400, lists-f...@useunix.net wrote:
> Is it different as in it gets rid of the annoying '\' characters that
> need to be at the end of every line. Unless you are saying that they
> aren't necessary?

They're continuation markers.  Lots of programs honour those when reading in
files, as does FVWM at present, so this isn't anything new, and the point of
using them is to allow people to improve readability.

-- Thomas Adam

Re: FVWM: [Draft] New Configuration Format

[lists-fvwm]

On Wed, Sep 21, 2016 at 11:27:47PM +0100, Thomas Adam wrote:
> On Wed, Sep 21, 2016 at 06:20:50PM -0400, lists-f...@useunix.net wrote:
> > Is it worth considering moving away from line-based processing for
> > entities like functions?
> > 
> > Changing the example in the document to something like:
> > 
> > Function -n func_name
> > i:DoImmediate,
> > c:DoClick,
> > i:DoImmediate,
> > i:TestRc (NoMatch) Break,
> > h:DoHold
> > EndFunction
> > 
> > Just a thought.
> 
> That's no different to the suggestion in the document, other than you've
> "regressed" back to what FVWM1.X used to do.  The "EndFunction" part doesn't
> add anything.
> 
> It's only "block" based because that's what we have now, and I see no reason
> why we need to retain that right now.
> 
> -- Thomas Adam
> 

Is it different as in it gets rid of the annoying '\' characters that
need to be at the end of every line. Unless you are saying that they
aren't necessary?

Wayne

Re: FVWM: [Draft] New Configuration Format

[lists-fvwm]

On Wed, Sep 21, 2016 at 07:32:53PM +0100, Thomas Adam wrote:
> On Wed, Sep 21, 2016 at 09:11:51AM -0700, elliot s wrote:
> > > take another look at the document, since it tells you how functions could 
> > > be specified.
> > 
> > I missed seeing the example, but it was as i thought.
> > A function is specified all on one line, which means  adding \ on all
> > but last line,
> > which means having to make sure  \ is on all but last line.
> > A source of copy/paste/delete errors while working on a function.
> 
> No different to how things are now, so it's not anything worth mentioning,
> really.
> 
> -- Thomas Adam
>

Is it worth considering moving away from line-based processing for
entities like functions?

Changing the example in the document to something like:

Function -n func_name
i:DoImmediate,
c:DoClick,
i:DoImmediate,
i:TestRc (NoMatch) Break,
h:DoHold
EndFunction

Just a thought.

Wayne

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.

Re: FVWM: [Draft] New Configuration Format

[Lucio Chiappetti]

On Wed, 21 Sep 2016, Thomas Adam wrote:

Secondly, take another look at the document, since it tells you how 
functions could be specified.


"the document", if I'm reading the right one, is just a very short sketch 
(3-4 pages) with some examples ... compared to the much longer man pages I 
studied carefully long time ago (not necessarily understanding all, 
specially what I was not needing at the time, and surely not remembering 
it all  :-) )


The point is that most users (I guess, that's valid for me anyhow) would 
only write a full configuration file once or twice in a lifetime, and edit 
it less than once per year.


I am also possibly even more extremist than other users, as I won't update 
fvwm version until I update my OS, and won't update my OS until I change 
my hardware (but at that moment I'M DAMN SURE I WANT TO GO ON USING FVWM).


So possibly the "change in config syntax" is just "another nuisance" of 
the sort I will be confronting when updating version (i.e. very seldom), 
and I suppose I am ready to consider it a "physiological" nuisance.


I am looking at my .fvwmrc (refurbished in 2015, using fvwm 2.5.26 under 
openSUSE 11.3), the one referred to near the end of
http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/window.html, and I see 
I use the following sort of items


- Desktop characteristics (name and size)
- general characteristics inherite from something (I do understand
  ColormapFocus FollowsFocus or ImagePath and forgot why the rest)
- Color sets (and FvwmBacker)
- general Styles (Style *)
- Styles for my modules and applications

- some event handlers (DestroyModuleConfig and recreation) and associated
  functions

- the big thing, the StartFunction which starsts applications and modules
  with some associated functions

- my window menus with some associated functions
- my root menu and some other menus
  (including some inherited stuff like for FvwmWinList

- the definition of a button box and pager, of a task bar etc,
  inclusive of some usage of FvwmCommand, SendToModule, FvwmScript

- the key and mouse bindings and some accelerators

Now for some of those items (typically those fitting on one line) I 
understand the matter is a change of syntax of the arguments. What I 
consider a "physiological nuisance".


It is less clear to me what I should do to update things which are 
multiline like AddToFunc +I ... or ModuleConfig or FVwmScripts or event 
handlers (the ones I understand less).


But I guess I will confront with them in due time. Next hardware change if 
I wait long enough that "new fvwm" is ready by then, or even second next 
if I change earlier :-)



--

Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html

Do not like Firefox >=29 ?  Get Pale Moon !  http://www.palemoon.org

Re: FVWM: [Draft] New Configuration Format

[Thomas Adam]

On Mon, Sep 19, 2016 at 02:31:34PM -0700, elliot s wrote:
> What would be an example of what a user defined function looks like?
> That's where most of the "needs easy reading and editing" happens.
> Also, i would have a space between option and value.
> So -f red, not -fred   (who's fred, and what's he doing in my rc file?)
> 

So "-fred" versus "-f red" is a facet of how getopt() works, and has no
bearing on how you specify the option with the value.  You can write it either
way.

Secondly, take another look at the document, since it tells you how functions
could be specified.

-- Thomas Adam

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

[elliot s]

What would be an example of what a user defined function looks like?
That's where most of the "needs easy reading and editing" happens.
Also, i would have a space between option and value.
So -f red, not -fred   (who's fred, and what's he doing in my rc file?)

Re: FVWM: [Draft] New Configuration Format

[Thomas Adam]

On Mon, Sep 19, 2016 at 05:03:47PM -0400, Stephen Dennison wrote:
> >
> > 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?

Doubtful.  We don't do that for FVWM right now, and indeed, any changes would
presumably happen through conversion scripts as they do now.  Not to mention,
as the configuration file is line-based, any "version" token would have to be
embedded on every line.

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

Yup.

> 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

Well, separating out -w wouldn't make the effect cumulative, which is what I'm
trying to demonstrate.

Note also that the CLI-like syntac is just that---in the style of, and there's
many instances of commands in the wild which have similar comma-separate
examples (sort(1)).

> Do you plan support actual string names of colorsets or are you just sort
> of shoehorning the -n name for the number?

It's all the same to mE

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

I'll update the document.

Thanks!

-- Thomas Adam

Re: FVWM: [Draft] New Configuration Format

[Dan Espen]

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.

-- 
Dan Espen

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 04:44:25PM -0400, Dan Espen wrote:
> Yes.
> 
> I tried to bring up the subject of readability.

OK.  Specifically?

-- Thomas Adam

Re: FVWM: [Draft] New Configuration Format

[Dan Espen]

Thomas Adam  writes:

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

Yes.

I tried to bring up the subject of readability.


(Warning, trimmed "To:" back to fvwm.org.)

-- 
Dan Espen

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