all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: 24914@debbugs.gnu.org
Subject: bug#24914: 24.5; isearch-regexp: wrong error message
Date: Mon, 4 Dec 2017 20:52:50 -0800 (PST)	[thread overview]
Message-ID: <3a58fdaf-10c0-42e6-8c74-753ce24b969e@default> (raw)
In-Reply-To: <878tehhlwo.fsf@users.sourceforge.net>

>     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.

Agreed.  Unless Emacs can be sure that in some context one of
them really means that the regexp is not complete.  If the
user can just keep typing to make a valid regexp then an error
msg (premature, not yet warranted) typically hurts more than it
helps, I think.

But if Emacs can't tell that, than sure, why not?

Timing can mean a lot also (but depends on the user and
how much thinking is going on).  It's not great to interrupt
immediately with an error msg if the user was still typing.

And clearly some of those error conditions do _not_ end
up translated as "incomplete input" messages - or they
should not, in any case.

Clearly someone made a decision about "Trailing backslash",
for instance, and it's a very good decision IMO.  That's a
more useful "the-pattern-is-incomplete" message than just
saying "incomplete input".

We are not the first to consider the list of error
conditions and what to do about this one or that one.
That doesn't imply that the judgment made previously is
the best one. It does suggest perhaps consulting those
who might have made it, or the larger emacs-devel community.

The behavior could be completely one-sided one way or
the other way.  Or it could be any kind of mix in between.
It is currently a mix, but obviously not a perfect one -
hence this bug report.  Which tradeoff is best?

> > 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)?

See above.  Isearch is incremental: you don't just enter
a complete regexp once and for all (as in `grep', for
instance.  If Emacs jumps the gun with a premature "error"
msg, that can be annoying, no?

> 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.

No, _not_ surely - I think.  Many (most? maybe, maybe not)
users are not all that positive about using Emacs regexps.

They should be able to interact with Isearch regexps
interactively, incrementally.  And yes, I think that it
can be helpful to let a user know that the current pattern
is incomplete as a regexp.

But hey, users are different.  I'd argue that we could
add an option, with the default setting the current
behavior (as I expect it is those less experienced that
the "incomplete" behavior could benefit the most, and
those more experience who could benefit most from the
specific "invalid" messages).  The latter are probably
also the ones most likely to try more complicated
regexps, which benefit the most, I expect, from precise
"invalid" messages.

Adding the behavior you propose as an option shouldn't
hurt.  But even for that you might want to propose it
at emacs-devel.  There might be people there more
familiar with different use cases or who know more about
the history of why the current behavior is as it is.

Just a suggestion.





  reply	other threads:[~2017-12-05  4:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-09 22:29 bug#24914: 24.5; isearch-regexp: wrong error message Drew Adams
2017-12-03 16:37 ` Noam Postavsky
2017-12-03 18:00   ` Drew Adams
2017-12-03 18:13     ` Noam Postavsky
2017-12-03 18:56       ` Drew Adams
2017-12-04  6:27         ` Noam Postavsky
2017-12-04 14:52           ` Drew Adams
2017-12-05  1:18             ` Noam Postavsky
2017-12-05  3:15               ` Drew Adams
2017-12-05  3:51                 ` Noam Postavsky
2017-12-05  4:52                   ` Drew Adams [this message]
2017-12-05 13:27                     ` Noam Postavsky
2017-12-05 15:31                       ` Drew Adams
2017-12-06  2:52                         ` Noam Postavsky
2017-12-08  9:48               ` Eli Zaretskii
2017-12-08 13:32                 ` Noam Postavsky
2017-12-08 14:35                   ` Eli Zaretskii
2017-12-10  2:18                     ` Noam Postavsky
2017-12-10  6:49                       ` Eli Zaretskii
2018-01-27  2:05                         ` Noam Postavsky
2017-12-04 15:18           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a58fdaf-10c0-42e6-8c74-753ce24b969e@default \
    --to=drew.adams@oracle.com \
    --cc=24914@debbugs.gnu.org \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.