Werner LEMBERG <w...@gnu.org> writes: >> Here is my multi-stage plan for that: > > I essentially agree with everything. Thanks for that plan. > >> b) our C++ engravers announce to the type system (and via that, to >> the documentation) which context properties they read, modify and >> write. There is no reason that this does not also include the Grob >> descriptions which are even now a special case of context property. > > In general, virtually all (public) Scheme functions of LilyPond > already have some documentation strings attached to it, and I think it > is probably one of the most important targets on the documentation > side to make them appear in the documentation. > >> d) \override xxx is equivalent to \override Bottom.xxx, [...] > > As soon as this works it would be extremely helpful if we could have a > command line flag to switch on tracing of those commands so that a > user can follow which \override gets applied which context. Actually, > this would be extremely helpful today too. > >>> And finding what comes after the \override staff.Something - is it >>> ##f. or #'4 or 4 or { 4} or what? >> >> #'4 and #4 and 4 should be quite equivalent in most cases... > > Currently, in case of error, we basically see the parser's or lexer's > error message which isn't very useful for the beginner. Is there any > possibility to fine-tune this as requested by Phil, in particular, > emitting the right usage as an example in the error message?
You mean, currently we basically see the default error message from the parser generator. Improving this involves basically accepting errors in input and acting on them by putting out hand-tailored messages. Currently, the parser is still undergoing significant restructuring work in major areas and mechanisms. That work entails a lot of time spent on ironing out parser conflicts where some input would correspond to multiple and diverging interpretations according to the current syntax. It is significant work ironing out those conflicts. Adding additional rules for erroneous input means more potential for conflict, so it would make the ongoing work even harder. I am working towards recognizing elements of the syntax in isolation, and then pasting them together. The "pasting together" is then done outside of the immediate control of the parser and can trigger independent error messages based on the assumption that at least the elements used for combining were, by themselves, recognized correctly. Those error messages can be more specific and helpful than the boilerplate parse errors from the parser generator. We have that, to some degree, concerning the type of music function arguments. If those don't match expectations, you'll get an error that usually is quite more specific and user-readable than "syntax error: unexpected STRING". However, putting more user-specific error rules in the syntax rules themselves increases the potential for syntax conflicts in the parser. As long as the major contruction work in there is not finished, the user benefits of such rules will likely be transitory, and it makes working on the parser even harder. So I would first like to get to a state where I consider the parser/syntax to be mostly "in harmony" with its design before adding user-helpful error rules that make further work harder. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel