Documentation on line wrapping?

[cpitclaudel]

It seems it's OK to write this:

pat1: \
  package(x), \
  package(y)

… but not this:

pat1 or \
pat2: package(x), package(y)

Is the syntax of the _tags file documented somewhere? The manual just says that each line should have a glob pattern and tags.

Thanks!

[gasche]

I'm afraid that line-wrappings are not documented because, as you notice, they are available somewhat inconsistently (it depends on the implementation of each lexer rule). I could try to make sure that all lexer rules accept it wherever whitespace is possible, and document this.

[cpitclaudel]

That'd be nice :)

[gasche]

triaging comment: This is a continuation of MPR#6087.

[gasche]

I looked at implementing this (relaxing the line-escape rules) when the issue was submitted, but it turns out that this is not trivial, because currently there are two parsers, one for glob patterns and one for configuration files, where the latter calls the former but only the latter handles newline and linecount (this relies on the assumption that glob patterns always fit a line). Implemeting this feature requires some refactoring, to ensure that both parsers support a common position-tracking interface. It is not hard, but it would take time, and this work is not a priority for me right now.

(I think this would be a nice task for a evening hacking session.)

Note if someone looks at implementing this: one thing that is odd there is that none of the parsers (for glob patterns and for configuration files) uses a parser generator. Instead there use a somewhat weird scheme where the lexer calls itself recursively to parse a whole AST, not just a single token. It works fine (and is not an issue for the refactoring mentioned above).
I would prefer a more standard lexer+parser divide, but this would introduce on a parser library or generator, which ocamlbuild user would frown upon: I would naturally use Menhir, but we don't want the dependency, same for combinator libraries, and ocamlyacc is both unpalatable (in my developer opinion) and I think a heavier and less convincing depndency than ocamllex, that is a simple and relatively uncontroversial tool. (Concretely, I could foresee a future where "ocamlyacc" is not distributed by default as part of the OCaml distribution, although I am not currently aware of such a plan.)