GNU bug report logs -
#24914
24.5; isearch-regexp: wrong error message
Previous Next
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):
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.