Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

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

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

Re: FVWM: [Draft] New Configuration Format

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

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

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.

Re: FVWM: [Draft] New Configuration Format

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,

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

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

Re: FVWM: [Draft] New Configuration Format

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

Re: FVWM: [Draft] New Configuration Format

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

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

Re: FVWM: [Draft] New Configuration Format

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

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,

Re: FVWM: [Draft] New Configuration Format

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.

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

Re: FVWM: [Draft] New Configuration Format

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

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

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

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

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

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

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

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

Re: FVWM: [Draft] New Configuration Format

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 c

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