Re: parser: more specific error messages; issue 3300 (issue 8506043)

[dak]

On 2013/04/12 04:07:15, Keith wrote:
> On 2013/04/08 18:07:50, dak wrote:
> > On 2013/04/08 17:58:43, Keith wrote:
> > > On 2013/04/08 16:05:20, dak wrote:
> >
> > > > Apropos: do you have an example of where your refactoring leads
to
> > > > a better error behavior (independent from the error message text
> > > > itself)?
> > >
> > > No. Finding the errors earlier simply allows shorter accurate
messages.
> >
> > You are aware that those two sentences flatly contradict each other?

> I simply couldn't fail to disagree with you less.

> Nobody didn't never use no canceling negatives nor negative qualifiers
on yes/no
> questions where I grew up.  Nevertheless, I think I might have
answered
> correctly above.

> No, I do not have any example of where my *fancy-word* leads to a
better error
> behavior, other than to allow the error message text itself to be more
specific.

I think the misunderstanding here might be your use of "earlier": in
either case, exactly the same expression is being flagged, so the
difference you can produce is not in the error location but just in the
text.

Your change will flag the same expression as previously but describe its
_type_ better, at the cost of omitting to mention a possible _reason_
for the problem.  That is not helpful for diagnosing the problem.  It is
merely helpful for suggesting that the error is not a random obstinacy
without rhyme or reason.

The change you made, namely
"unexpected markup (without \\lyricmode)"
does not do much to suggest LilyPond is not just being obtuse.  Maybe
something like
"unexpected markup (missing \\lyricmode ?)"
is better here? After all, \lyricmode is just a reasonable guess, not
more or less.  Or something more verbose like
"a markup here would require \\lyricmode".

https://codereview.appspot.com/8506043/