unofficial mirror of bug-gnu-emacs@gnu.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: Tue, 5 Dec 2017 07:31:21 -0800 (PST)	[thread overview]
Message-ID: <cde1289b-bb88-4315-aba0-0e002cab30de@default> (raw)
In-Reply-To: <87609lgv8r.fsf@users.sourceforge.net>

> > 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".
> 
> Right, but I can't see why the same shouldn't apply to
> "Unmatched \\{" and all the others.

Treating them all the same is one possibility.
Not the best one, I think, but one possibility.

> > 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.
> 
> That code seems to have been there since 1992 "Initial
> revision", so it's not clear what, if any, considerations
> were made.

It might not be clear, but that doesn't mean there weren't
good reasons for that judgment.  (And no, I'm not saying
that a different judgment can't be made now.)

And certainly some of those around then, including
deciders probably, are still around today.  Perhaps
RMS has an opinion or recollection about this?

> > 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?
> 
> We already get an "error" message, it says "incomplete".
> The question is why shouldn't it instead say *why* it's
> incomplete.

I thought your proposal was to, in all cases, eliminate
saying it is incomplete in favor of the specific
regexp-invalidity error text.

Such error text does not, generally and directly, tell
users that the input is incomplete.  Users very familiar
with regexps might understand that such a msg implies
that input is incomplete, but not everyone will get that.

> > Adding the behavior you propose as an option shouldn't
> > hurt.
> 
> It hurts, because it adds yet another option, which makes a user's job
> of going through them and deciding which ones make sense that much
> harder (yes, just this particular addded option won't make much
> difference, but still).

Users who are very familiar with Emacs regexps will be
the ones to benefit most from the specific regexp-validity
msgs, IMO.  They should have no problem customizing an
option.  Users unfamiliar with Emacs or Emacs regexps will
get the simpler default behavior: your input pattern is
not yet complete.

If you feel strongly about this and are opposed to
adding a user option, consider proposing the change
you want to emacs-devel.

This particular bug is about one case: just the
particular "incomplete input" message case cited.
Fixing this bug shouldn't require changing the
basic behavior, though that is certainly one
possibility.

You apparently think there is never any value in
telling users that the input pattern is not
complete as a regexp.  I disagree.  We apparently
agree that at least in some cases the specific
regexp-invalidity message is more helpful.

There is a spectrum of possibilities here.  I see
no special reason why the right approach should
be all or none.

> > 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.
> 
> I hope so.





  reply	other threads:[~2017-12-05 15:31 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
2017-12-05 13:27                     ` Noam Postavsky
2017-12-05 15:31                       ` Drew Adams [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=cde1289b-bb88-4315-aba0-0e002cab30de@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).