[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grammatical forms in translatable texts

From: Akim Demaille
Subject: Re: Grammatical forms in translatable texts
Date: Wed, 22 Apr 2020 07:57:10 +0200

Hi Frank,

> Le 20 avr. 2020 à 22:53, Frank Heckenbach <address@hidden> a écrit :
> Akim Demaille wrote:
>>> YYCASE_(2, YY_("syntax error.\nunexpected token: '%s'\nExpected token: 
>>> '%s'"));
>>> YYCASE_(3, YY_("syntax error.\nunexpected token: '%s'\nExpected token: '%s' 
>>> or '%s'"));
>>> YYCASE_(4, YY_("syntax error.\nunexpected token: '%s'\nExpected token: '%s' 
>>> or '%s' or '%s'"));
>>> YYCASE_(5, YY_("syntax error.\nunexpected token: '%s'\nExpected token: '%s' 
>>> or '%s' or '%s' or '%s'"));
>> This is sooo different from what compilers do!  Not to mention
>> that, for lack of a specific prefix, tools such as Emacs will
>> not be able to highlight this part as belonging to a diagnostic.
> That was my first thought, too. But I think the issue is mainly
> about the line breaks. One could instead put the "form" in one line,
> or Bison could insert the prefix in each line; of course, this would
> require a bit of effort (finding the line breaks etc.), but seems
> doable as well.

I cannot do that.  I have no idea what the user is doing in yyerror.
Bison forges the error message, and passes it to the user.  She is
in charge of delivering it to the user, possibly after having added
the location somewhere.  And maybe increment some count of number of
errors, etc.  And possibly opening a GUI alert window to pass the
message.  Or syslog it.

I don't think either that calling "yyerror" several times, once for
each line, would be appropriate in all the cases.

(Then again, we are talking about several distinct issues: (i) the canned
error message that goes into generated parser, and (ii) bison's own
diagnostics.  Here I'm answer to (i).)

AFAICT from the different cases where I saw people hack the system
to get some control over the way tokens are displayed, I believe most
users don't really care about how correct the resulting sentence is.
Those who do can go "%define parse.error custom" and take control.

I can add "%define parse.error form" if you think that would be
useful, but I don't want it to change the behavior of "verbose" or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]