Werner LEMBERG <w...@gnu.org> writes: >> Rather than proposing something by way of example, I would like to >> see all proposals in the form of a parser patch that does not >> introduce extra shift/reduce or reduce/reduce conflicts, and >> maintains general backward compatibility. If a proposer manages to >> get that far, I promise I will take a serious look at it. > > You are exaggerating, aren't you? With this prerequisite, very useful > stuff like `q' would have never been implemented. It took David a > long time to generalize it,
Uh, no. Not "generalize" it. _Fix_ it. The implementation was totally broken and incompatible with LilyPond's normal way of operating (namely, it did not survive copying of music, and LilyPond copies music in a lot of situations). It was a bad hack on top of the parser, based on assumptions that were invalid. It became only possible to approach having it work sensibly when issue 2240 was implemented for different reasons, because before 2240 there was not even a distinction between chords and single notes in the music data structure, and without that distinction, q simply _could_ not work reliably. > but IMHO it was worth the trouble. In my opinion, it wasn't. Just because I found a way to clean up after people that did not worry about breaking things they don't understand in return for a modicum of convenience does not mean that this was a good idea to start with. We are just now starting to see the tip of the iceberg of users having to deal with issue 2240. Bringing LilyPond input into closer relation with the resulting music expressions (without changing the resulting stream events) was important for other reasons, most importantly for being able to work with music functions in the context of chord elements. That it brought it into reach to fix the totally broken q was a side-effect (or rather, its main-effect, but in an area of less importance) that would, on its own, not have warranted the compatibility drawbacks of issue 2240. > Perhaps we should start differently: Instead of making ad-hoc syntax > suggestions, let's collect experienced user reports about the most > annoying LilyPond syntax issues. The stress lies on *user*, not > developer. Then parser experts can have a look whether changes are > possible and useful. A collection of issues rather than a collection of purported remedies might indeed make more sense. As an example, take "I find the need to write something like \violin2". One remedy is to allow numbers into identifiers. This can take a large variety of forms. Keith's patch is basically a sketch of very specific form, with advantages and disadvantages not all inherently tied with the issue as such. The general issue still has to answer the question "What with \skip4"? Keith's answer to this particular issue is "only permitted inside of music", and his answer to "what about top level which currently _is_ music" is "let's make it almost, but not quite, non-music". And consequently his implementation of this concept requires meddling with both lexer and parser and consistency of lexical units. The details of this meddling could be improved, but the basic need remains. So my approach to that issue in general is different, and in particular to the question "what with \skip4" is "what with it?". I am for keeping "\skip4" equivalent to "\skip 4" and, consequently, for keeping "\violin2" equivalent to "\violin 2" and, by the way, equivalent to "\violin #(1+1)" as well. Namely make "\violin" aware that it requires a number to form a reference. This does not require meddling with the lexer, but it certainly requires meddling with the parser. And, of course, it opens another can of worms, and it will take quite a bit of work to smoothen the edges of this can since it is quite a bigger can. And there is further work pending before it becomes even feasible opening it. Which sounds a lot like q actually. In generally, it is a good idea to move LilyPond in a direction where it becomes feasible to open a number of cans of worms: it usually means a robust and flexible direction. But that does not mean that every can coming into reach then actually is worth opening, and quite a few are exclusive, meaning that their opening locks down the possibilities of future changes again. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
