On Sun, Aug 24, 2014 at 12:17:07AM +0100, Thomas Adam wrote:
> On Sun, Aug 24, 2014 at 12:07:29AM +0100, Dominik Vogt wrote:
> > I've just pushed a commit that cleans up the notation a bit and
> > does a couple of steps in the direction of a real *bnf.  I've also
> > converted what we have to abnf (rfc5243) which is more expressive
> > than ebnf.
> 
> Righty-o.  I'll take a look at ABNF.  Hopefully it's close to some form
> of BNF I've used before.

It's the bnf variant used in rfcs.  No big deal, but it has some
nifty extensions.

 * Replace | with /
 * You can specify the allowed number of repetitions
   *RULE -- 0 to infinity repetitions
   <n>RULE -- <n> repetitions
   <n>*RULE -- <n> or more repetitions
   <n>*<m>RULE -- <n> to <m> repetions
   *<m>RULE -- 0 to <m> repetitions
 * Literal ASCII characters can be written as hexadecimal or
   decimal numbers, e.g. %x40 and %d64 are equivalent to "@".
 * Continuation lines are indented.

> > There are several pitfalls to be aware of:
> > 
> >  * For some commands, the documentation is ambiguous or wrong.
> >    Sometimes there are so many options that they interfere with one
> >    another, and sometimes the syntax description might allow some
> >    combination of options that is actually not allowed.
> 
> Right---some of the commits to fvwm-workers@ from me have been as a
> direct result of my trying to correlate the documentation and the code
> itself, since as you rightly point out, the code is so expressive, the
> number of permutations of some options isn't documented.
> 
> I wonder though what impact this will have?  I mean, can we infer a
> pathological case and disgregard any "non-standard" interactions of
> options if they occur?  One immediate example I can think of (which I'll
> check) is the 'Resize' command.  I know I changed it to support
> direction-based pointer warping and can see already I've introduced
> problems there with different command combinations.  Oops.  I'll assess
> the impact.
> 
> >  * Many commands ignore the reset of the command line once they are
> >    happy with what they've already parsed.
> > 
> > > Please take a look---we're not quite there yet, but hopefully I've given
> > > this a heaftier shove in the right direction.
> > 
> > Looks good to me, but I fear that we've only done 5% of the work.
> > Next week I'll have more time to help.  Maybe I can try to write
> > down the general parsing algorithm in abnf.
> 
> OK.  I'm keen to flesh-out the existing commands further; I'll continue
> this tomorrow. 

Maybe you can keep an eye out for rules common to multiple
commands.  Possible things that come to my mind:

 * Coordinate prefixes and suffixed from move-type commands.
 * Width and height prefixes and suffixes from resize type
   commands.
 * Many commands accept either BOOL arguments of BOOL_OR_TOGGLE.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Reply via email to