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


Message #33 received at 24914 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24914 <at> debbugs.gnu.org
Subject: Re: bug#24914: 24.5; isearch-regexp: wrong error message
Date: Mon, 04 Dec 2017 20:18:02 -0500
Drew Adams <drew.adams <at> oracle.com> writes:

> What I cited are cases where we do flag _particular kinds_
> of invalid regexps, and so tailor the error msg.

I'm not sure if you're citing actual code we have right now, or just
some hypotheticals.  In isearch.el, we pretty much do the opposite of
tailor the error message.

>> Actually, I'm wondering what's the point of isearch showing
>> "incomplete" instead of the actual regexp invalid error.
>> I.e., why not instead of
>> 
>>     \ [incomplete]
>>     \{ [incomplete]
>>     \{4 [incomplete]
>>     \{4000 [incomplete]
>>     \{4000\ [incomplete]
>>     \{4000\}
>> 
>> show this:
>> 
>>     \ [Trailing backslash]
>>     \{ [Unmatched \{]
>>     \{4 [Unmatched \{]
>>     \{4000 [Unmatched \{]
>>     \{4000\ [Trailing backslash]
>>     \{4000\}
>
> Feel free to work on that.  You might run into some cases
> that are not so clear-cut.  But you might well improve
> things generally in some way.

I meant just the following patch, you can try it out easily:

--- i/lisp/isearch.el
+++ w/lisp/isearch.el
@@ -2850,10 +2850,6 @@ isearch-search
     (invalid-regexp
      (setq isearch-error (car (cdr lossage)))
      (cond
-      ((string-match
-	"\\`Premature \\|\\`Unmatched \\|\\`Invalid "
-	isearch-error)
-       (setq isearch-error "incomplete input"))
       ((and (not isearch-regexp)
 	    (string-match "\\`Regular expression too big" isearch-error))
        (cond

Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>>     /* If sizeof(int) == 2, then ((1 << 15) - 1) overflows.  */
>>     #define RE_DUP_MAX (0x7fff)
>> 
>> Does Emacs even support 16 bit platforms?
>
> Emacs never did (the MS-DOS port of Emacs runs in i386 32-bit
> protected mode on top of a 16-bit OS).  But regex.c did, at some very
> distant past, to support the 16-bit MS compiler, or at least it tried
> to.

So changing to 2^31 as the max should be fine, right?

--- i/src/regex.h
+++ w/src/regex.h
@@ -270,8 +270,10 @@
 #ifdef RE_DUP_MAX
 # undef RE_DUP_MAX
 #endif
-/* If sizeof(int) == 2, then ((1 << 15) - 1) overflows.  */
-#define RE_DUP_MAX (0x7fff)
+/* If sizeof(int) == 4, then ((1 << 31) - 1) overflows.  This used to
+   be limited to 0x7fff, but Emacs never supported 16 bit platforms
+   anyway.  */
+#define RE_DUP_MAX (0x7fffffff)
 
 
 /* POSIX `cflags' bits (i.e., information for `regcomp').  */






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

Previous Next


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