Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup <address@hidden> wrote:
>
> 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.

Hmm, this sounds complicated.  Do you mean that implementing more
informative ("custom") error messages with current parser will wreak
havoc, but if we simplify the parser first, it would be possible to do
this in a sane way?


On Sat, Sep 15, 2012 at 11:53 AM, Phil Holmes <address@hidden> wrote:
> ----- Original Message ----- From: "David Kastrup" <address@hidden>
>> You need to elaborate.  It is not clear what you mean with that, and
>> what kind of remedy you envision.
>
> \new Staff works.  \New staff doesn't.  There's no reason for that - we
> don't have two separate \new \New commands that do different things, nor two
> contexts Staff and staff that are different.  Worse is that \slurUp works
> but only with that precise casing.  TBH this specific one doesn't cause me
> worry, since I remember it, but there are much more arcane casings that I
> have to refer to the manual to find - so I can remember the command, but not
> the casing!

I think we should make the casing/naming uniform across all names, for example:
\New Staff
\SlurUp
LyricExtenderEngraver
SomePropertyName

> From a user perspective, it would be much simpler if everything
> they write was ToLower()-ed before further processing.

This sounds interesting to me, but David signalled an important
problem - distinguising notenames (which are always lower case) from
grob names ant other things.
Another solution would be to have Frescobaldi auto-correct the casing.