bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#24914: 24.5; isearch-regexp: wrong error message


From: Noam Postavsky
Subject: bug#24914: 24.5; isearch-regexp: wrong error message
Date: Mon, 04 Dec 2017 22:51:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

> I was citing what I thought were such cases in the current
> isearch.el code - cases where we do not just say "Invalid
> Regexp".  We say things like this:
>
>  Too many words
>  Too many spaces for whitespace matching

In that case, the regexp is constructed by Emacs on behalf of the user,
so it makes sense to translate the error message so that it matches the
user operation.

>  Unmatched [ or [^

AFAICT, the isearch.el code doesn't write that message, but rather reads
it.

> Granted, the last is used only in `isearch-query-replace.
>
> My point was that in some existing cases (not many,
> admittedly), we do try to give a more precise error
> message when signal `invalid-regexp' is detected.
>
> But I'm not sure what you're arguing, if you are arguing.

The C regex code produces the following error messages when parsing
regexps:

  {
    gettext_noop ("Success"),   /* REG_NOERROR */
    gettext_noop ("No match"),  /* REG_NOMATCH */
    gettext_noop ("Invalid regular expression"), /* REG_BADPAT */
    gettext_noop ("Invalid collation character"), /* REG_ECOLLATE */
    gettext_noop ("Invalid character class name"), /* REG_ECTYPE */
    gettext_noop ("Trailing backslash"), /* REG_EESCAPE */
    gettext_noop ("Invalid back reference"), /* REG_ESUBREG */
    gettext_noop ("Unmatched [ or [^"), /* REG_EBRACK */
    gettext_noop ("Unmatched ( or \\("), /* REG_EPAREN */
    gettext_noop ("Unmatched \\{"), /* REG_EBRACE */
    gettext_noop ("Invalid content of \\{\\}"), /* REG_BADBR */
    gettext_noop ("Invalid range end"), /* REG_ERANGE */
    gettext_noop ("Memory exhausted"), /* REG_ESPACE */
    gettext_noop ("Invalid preceding regular expression"), /* REG_BADRPT */
    gettext_noop ("Premature end of regular expression"), /* REG_EEND */
    gettext_noop ("Regular expression too big"), /* REG_ESIZE */
    gettext_noop ("Unmatched ) or \\)"), /* REG_ERPAREN */
    gettext_noop ("Range striding over charsets"), /* REG_ERANGEX  */
  };

When doing isearch-*-regexp, most of those errors are converted into
"incomplete" (i.e., *less* precise).  But I think it would be more
helpful to show the original error message.

> But I don't think it follows that it would be more helpful to
> most users to show the invalid-regexp description in cases
> where Emacs can really tell that the input is necessarily
> incomplete.  I suspect that it is quite common for that
> "incomplete input" message to be helpful.

How does it help (compared to the more precise message)?  Seems to me
that telling the user they haven't finished entering the regexp isn't
especially helpful; surely the user already knows they haven't finished
typing yet.





reply via email to

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