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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Wed, 9 Nov 2016 22:31:01 UTC

Severity: minor

Tags: confirmed, fixed, patch

Found in versions 24.5, 25.2

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24914 <at> debbugs.gnu.org
Subject: bug#24914: 24.5; isearch-regexp: wrong error message
Date: Tue, 05 Dec 2017 08:27:48 -0500
Drew Adams <drew.adams <at> oracle.com> writes:

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

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

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

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

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




This bug report was last modified 7 years and 119 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.