> > I've pushed an attempt to define character classes, single character
> > quoting, unqouted and quoted strings, STRING and TOKEN.
> >
> > Note that we need to go over the actual uses of STRING to see
> > whether they should be using something else.
>
> That's an interesting point -- consider *any* command or option, and
> invariably you can have:
>
> COMMAND "Option" / 'Option' / `Option`
>
> Currently, the way we're documenting these options isn't catering for
> the quoting rules which the parser allows for---even if it's ignoring
> them (although in cases like PipeRead this does have semantic
> differences---although by the time it reaches the shell, we don't care
> how much of a mess someone might have landed themselves in).
You are right. The current code mixes all sorts of things in an order
that lacks proper definition:
* Reading command lines from various sources (module input, file input,
PipeRead), including parsing of continued lines.
* Lazy tokenisation of command lines (i.e. the next token is parsed
when it's needed). Tokenisation actually does not suit all commands.
Some take the remaining part of the command line as a literal string
(Echo, function definitions, ...), and some have more complex needs,
e.g. commands that parse conditions containing sub-tokens separated
by whitespace. Sometimes it is required that a token begins with a
quote character.
* De-quoting of tokens. This is done for the tokens before their
contents are interpreted. So, the POSINT rule should really be a
POSINT_TOKEN rule, but I wouldn't do that now because its a lot of
work and the gain is doubtful.
* Variable expansion does not fit into the parsing process at all.
So we'll probably end up with several separate parsing steps (with their
own Abnf each) and generation steps in between (expansion, de-quoting).
> However in documenting that minor detail for diffrent options would make
> the ABNF almost unreadable in my eyes, so I wonder how useful it is?
Not at all for now. At the moment we have a strict separation of the
general parsing which is done in a central place, and the command parsing
which is done separately in each function. The most important work at
the moment is to capture how the commands parse their arguments. I've
started to even write down which parsing functions they use, but there are
some really awful commands, e.g. windowshade: The first argument may be
"Last" (which is only walid if the window has been unshaded before after
being shaded with a direction argument), or it may be a direction (which
may be an invalid string). Then, if both are missing or the one used was
not valid, a bool argument is parsed instead, with the additional meaning
that "2" is also interpreted as "false". That's awfully difficult to
describe in Abnf. 8-P
> Another example are function definitions:
>
> AddToFunc TeddyBear "I" Echo "xteddy"
> AddToFunc "TeddyBear"
> + "C" Exec exec xteddy
> + M Nop
>
> All of these are valid (AFAICT). So we're at a slight quandry here,
> because we've only documented the bare minimum, and your quoting
> definiions are fabulous, Dominik---the question I'm asking is how/if we
> apply them to every single option we've already documented, and whether
> that's a useful thing to do?
No, the de-quoting step must be done outside the parser but I'm not sure
how to write all this down.
> One other thing to note (which I don't think warrants a separate
> thread), is can you check the following for me (lines 1056-1063):
>
> MENUCONTEXT =/ "Window" /
> "Interior"
> "Interior =/ "Title"
> "Interior =/ ("Button" INT) "Icon"
> "Interior =/ "Item"
> "Interior =/ "Context"
> "Interior =/ "This"
> "Interior =/ ("Rectangle" MENUCONTEXTGEOMETRY)
>
> I'm not convinced the syntax is correct there, but I'm not sure
> precisely what it's getting at either?
MENUCONTEXT = "Window" / "Interior" / "Title" / ("Button" INT) / "Icon" / ...
can be written as
MENUCONTEXT = "Window"
MENUCONTEXT =/ "Interior"
MENUCONTEXT =/ "Title"
MENUCONTEXT =/ ("Button" INT)
MENUCONTEXT =/ "Icon"
MENUCONTEXT =/ ...
See 3.3 in the rfc: http://tools.ietf.org/html/rfc5234
=/ is just a form of multi line continuation of a alternative rule:
FOO = a / b / c
or
FOO = a / b /
c
is equivalent to
FOO = a / b
FOO =/ c
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
