Re: [PATCH] Introduce-alignment-mechanism-for-error-messages

[Alex Rozenman]

Hi Akim,

Before I'll proceed, could you please verify that I understand the
'gettext' correctly ?
For example:

        const char *msg1 = _("symbol not found");
        const char *msg2 = _("in production");
        const char *msg3 = _("before");
        unsigned indent = 0;

        complain_at_indent (text_loc, &indent, _("invalid reference: %s"),
                            quote (text));
        indent += 4;
        if (midrule_rhs_index)
          complain_at_indent (rule->location, &indent, "%s %s %s $%d: %.*s",
                              msg1, msg2, msg3,midrule_rhs_index, len, cp);
        else
          complain_at_indent (rule->location, &indent, "%s %s: %.*s",
                              msg1, msg2, len, cp);

In "complain_at_indent" I don't even need _N, because it is a "pure"
format string; Another option:

if (midrule_rhs_index)
          complain_at_indent (rule->location, &indent, _("%s %s before
$%d: %.*s"),
                              msg1, msg2, midrule_rhs_index, len, cp);
        else
          complain_at_indent (rule->location, &indent, "%s %s: %.*s",
                              msg1, msg2, len, cp);

(here I expecting that "before" word will be translated as a part of
format string).
Which option is better ?

Another issue: I am getting now an error in 'bison.texinfo' file, on
the following line:

"As far as we know, these limitations \emph{can} be alleviated.  All it takes"

When I change \ to @ the error disappears.
Is it a problem with my 'texi' tools, or it's just a typo ?

Alex

On Wed, Sep 16, 2009 at 2:05 PM, Akim Demaille <address@hidden> wrote:
>
> Le 14 sept. 2009 à 23:43, Alex Rozenman a écrit :
>
>> Hi Akim, Hi Joel, All,
>>
>> I would like to install the following (attached) patch in order to make
>> the
>> error messages more readable. Please review the presented mechanism and
>> let
>> me know if there are any objections/comments.
>
> Hi Alex,
>
>        * src/location.h: location_print: return number of written
>
> This is incorrect: put the name of the entities in parens.
>
>        characters.
>        * src/location.c: Implemented here.
>        * src/complain.h: New functions: warn_at_indent,
>        complain_at_indent.
>
> Likewise.  See other entries in the ChangeLog to have a model.
>
>        * src/complain.c: Implemented here. error_message function:
>        update *indent_ptr accordingly.
>        * src/scan-code.l: Use warn_at_indent/complain_at_indent.
>        * src/named-ref.at: Adjust tests.
>
>
>
> Please use "res" as variable name when they are the result of the function
> (location_print for instance).
>
> +/* Will return number of printed characters.  */
> +unsigned location_print (FILE *out, location loc);
>
> Use the imperative: Return the number...
>
>
>
>          /* Create the explanation message. */
>          obstack_init (&msg_buf);
>
> -         obstack_fgrow1 (&msg_buf, "  possibly meant: %c", dollar_or_at);
> +         obstack_fgrow1 (&msg_buf, "possibly meant: %c", dollar_or_at);
>          if (contains_dot_or_dash (id))
>            obstack_fgrow1 (&msg_buf, "[%s]", id);
>          else
>
>
> Missing translation.  Unless it is translated here:
>
> -            warn_at (id_loc, _("%s"), (char *) obstack_finish (&msg_buf));
> +            warn_at_indent (id_loc, &indent, _("%s"),
> +                            (char *) obstack_finish (&msg_buf));
>
> This is not good on two accounts.  First, it probably means that the
> format-string is built, which is not good for translators, as I noted
> elsewhere.  And also, there is no marker on the "possibly meant" string
> above so that the translators be warned that this string must be provided a
> translation.  Using _("...") does two things: it tells the gettext machinery
> that the string will have to be translated (sort of static analysis if you
> wish), and at run time, it really looks for the translation.
>
> Here, you need to use N_.  You should read
> http://www.gnu.org/software/gettext/manual/gettext.html#Sources.
>
>
>
> Other than that, the patch is fine.  But I think I'm changing my mind about
> the "note:" mechanism you once proposed.  I fear that Emacs will understand
> the submessages as distinct errors, instead of a single error.
>  Unfortunately the GNU Coding Standard is not really good enough here, we
> should probably ask for an update.
>
>        http://www.gnu.org/prep/standards/standards.html#Errors
>
>



-- 
Best regards,
Alex Rozenman (address@hidden).