GNU bug report logs - #7534
24.0.50; G-g within Isearch regexp mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7534 in the body.
You can then email your comments to 7534 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; G-g within Isearch regexp mode
Date: Thu, 2 Dec 2010 20:47:16 +0100

Recipe:
0) Start Emacs (-Q)
1) Place point at the beginning of the *scratch* buffer.
2) Search for the regexp "iss" (C-M-s iss) --> The last `s' is
unmatched as expected, OK.
3) Type C-g --> The unmatched part disappears. Everything OK so far.
4) Now repeat steps #2 and #3 with the regexp "is[". --> This time C-g
behaves differently. Instead of deleting the unmatched part, it ends
Isearch mode.


The fail seems to appear whenever `[' is the first character in the
unmatched part. For instance:
 * C-M-s iss[ C-g --> Works as expected (unmatched part deleted).
 * C-M-s is[blablabla --> Doesn't work as expected (Isearch cancelled).


-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Thu, 02 Dec 2010 22:31:48 +0000

> Recipe:
> 0) Start Emacs (-Q)
> 1) Place point at the beginning of the *scratch* buffer.
> 2) Search for the regexp "iss" (C-M-s iss) --> The last `s' is
> unmatched as expected, OK.
> 3) Type C-g --> The unmatched part disappears. Everything OK so far.
> 4) Now repeat steps #2 and #3 with the regexp "is[". --> This time C-g
> behaves differently. Instead of deleting the unmatched part, it ends
> Isearch mode.
>
> The fail seems to appear whenever `[' is the first character in the
> unmatched part. For instance:
>  * C-M-s iss[ C-g --> Works as expected (unmatched part deleted).
>  * C-M-s is[blablabla --> Doesn't work as expected (Isearch cancelled).

IMO, this is consistent behavior.  As the message says after typing `['
it's incomplete input, so C-g behaves exactly like if there is no input
for `[' (and an unfinished sequence of characters that follows it).

So the main principle here is that "incomplete input" means "no input"
for Isearch, and given this rule all your examples work as expected, i.e.

"C-M-s is[ C-g" works like "C-M-s is C-g"
"C-M-s iss[ C-g" works like "C-M-s iss C-g"
"C-M-s is[blablabla C-g" works like "C-M-s is C-g"

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Fri, 3 Dec 2010 08:57:23 +0100

On Thu, Dec 2, 2010 at 23:31, Juri Linkov <juri <at> jurta.org> wrote:
[...]
>
> IMO, this is consistent behavior.  As the message says after typing `['
> it's incomplete input, so C-g behaves exactly like if there is no input
> for `[' (and an unfinished sequence of characters that follows it).
>
> So the main principle here is that "incomplete input" means "no input"
> for Isearch, and given this rule all your examples work as expected, i.e.
>
> "C-M-s is[ C-g" works like "C-M-s is C-g"
> "C-M-s iss[ C-g" works like "C-M-s iss C-g"
> "C-M-s is[blablabla C-g" works like "C-M-s is C-g"
>

Thanks for thinking on this, Juri.

Indeed, the current behaviour seems to be like you mentioned
("incomplete input" means "no input"), but IMO that doesn't fit well
user's needs. If the user is searching for "is[blablabla", and
suddenly changes his(her) mind, I think C-g should allow to get rid of
the unmatched part.

So, IMO, the main principle for C-g (within Isearch mode) should be:
* if there is unmatched and/or incomplete input --> Delete it.
* Otherwise --> Exit Isearch mode.

-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Sun, 05 Dec 2010 23:11:57 +0000

> So, IMO, the main principle for C-g (within Isearch mode) should be:
> * if there is unmatched and/or incomplete input --> Delete it.
> * Otherwise --> Exit Isearch mode.

Please try the following patch.  Does it provide the behavior
you are asking for?

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2010-10-02 22:37:21 +0000
+++ lisp/isearch.el	2010-12-05 23:08:19 +0000
@@ -1253,7 +1253,7 @@ (defun isearch-abort ()
   (interactive)
 ;;  (ding)  signal instead below, if quitting
   (discard-input)
-  (if isearch-success
+  (if (and isearch-success (not isearch-error))
       ;; If search is successful, move back to starting point
       ;; and really do quit.
       (progn

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Mon, 6 Dec 2010 11:41:32 +0100

On Mon, Dec 6, 2010 at 00:11, Juri Linkov <juri <at> jurta.org> wrote:
>> So, IMO, the main principle for C-g (within Isearch mode) should be:
>> * if there is unmatched and/or incomplete input --> Delete it.
>> * Otherwise --> Exit Isearch mode.
>
> Please try the following patch.  Does it provide the behavior
> you are asking for?
>

It does. Thank you.

PS: The patch bellow is like your's, but it also updates the comment
accordingly.


=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2010-10-16 14:11:06.000000000 +0200
+++ lisp/isearch.el	2010-12-06 11:27:33.000000000 +0100
@@ -1244,9 +1244,9 @@
   (interactive)
 ;;  (ding)  signal instead below, if quitting
   (discard-input)
-  (if isearch-success
-      ;; If search is successful, move back to starting point
-      ;; and really do quit.
+  (if (and isearch-success (not isearch-error))
+      ;; If search is successful and there is no incomplete regexp,
+      ;; move back to starting point and really do quit.
       (progn
         (setq isearch-success nil)
         (isearch-cancel))




-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Sat, 25 Dec 2010 02:47:44 +0000

>>> So, IMO, the main principle for C-g (within Isearch mode) should be:
>>> * if there is unmatched and/or incomplete input --> Delete it.
>>> * Otherwise --> Exit Isearch mode.
>>
>> Please try the following patch.  Does it provide the behavior
>> you are asking for?
>
> It does. Thank you.

I think the behavior of Isearch that Dani proposes is reasonable because
it seems this is how `isearch-abort' was supposed to work since its
comment says "If search has an incomplete regexp" but this branch currently
is never reached.  So I'd like to install it to the trunk.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: 24.0.50; G-g within Isearch regexp mode
Date: Tue, 4 Jan 2011 12:42:19 +0100

On Sat, Dec 25, 2010 at 03:47, Juri Linkov <juri <at> jurta.org> wrote:
>
> I think the behavior of Isearch that Dani proposes is reasonable because
> it seems this is how `isearch-abort' was supposed to work since its
> comment says "If search has an incomplete regexp" but this branch currently
> is never reached.  So I'd like to install it to the trunk.
>

This is a fairly simple change. Please, could a maintainer take a look
to the proposed patch?

TIA.

-- 
Dani Moncayo

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Chong Yidong <cyd <at> stupidchicken.com>
Cc: Juri Linkov <juri <at> jurta.org>, 7534 <at> debbugs.gnu.org
Subject: bug#7534: C-g in Isearch regexp mode
Date: Sat, 15 Jan 2011 10:57:59 +0100

>On Sat, Dec 25, 2010 at 03:47, Juri Linkov <juri <at> jurta.org> wrote:
>>
>> I think the behavior of Isearch that Dani proposes is reasonable because
>> it seems this is how `isearch-abort' was supposed to work since its
>> comment says "If search has an incomplete regexp" but this branch currently
>> is never reached.  So I'd like to install it to the trunk.
>>

> This is a fairly simple change. Please, could a maintainer take a look
> to the proposed patch?

Hello? Is anyone out there?   ;-)

-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
	7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: C-g in Isearch regexp mode
Date: Sat, 15 Jan 2011 10:51:52 -0500

>>> I think the behavior of Isearch that Dani proposes is reasonable because
>>> it seems this is how `isearch-abort' was supposed to work since its
>>> comment says "If search has an incomplete regexp" but this branch currently
>>> is never reached.  So I'd like to install it to the trunk.

I haven't had time to dig into it and understand the details, but
I'll trust Juri on this one.


        Stefan

Message #34 received at 7534-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7534-done <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
	Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#7534: C-g in Isearch regexp mode
Date: Sun, 16 Jan 2011 01:06:12 +0000

>>>> I think the behavior of Isearch that Dani proposes is reasonable because
>>>> it seems this is how `isearch-abort' was supposed to work since its
>>>> comment says "If search has an incomplete regexp" but this branch currently
>>>> is never reached.  So I'd like to install it to the trunk.
>
> I haven't had time to dig into it and understand the details, but
> I'll trust Juri on this one.

Installed to the trunk.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> jurta.org>
Cc: 7534 <at> debbugs.gnu.org
Subject: bug#7534: what about committing the patch also to emacs-23?
Date: Fri, 4 Feb 2011 08:54:20 +0100

Hi,

Given that the patch for this bug was tiny and inoffensive, what do
you think about commiting it also in the emacs-23 branch (before the
23.3 release)?

TIA

--
Dani Moncayo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
	7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: what about committing the patch also to emacs-23?
Date: Fri, 04 Feb 2011 09:40:29 -0500

> Given that the patch for this bug was tiny and inoffensive, what do
> you think about commiting it also in the emacs-23 branch (before the
> 23.3 release)?

We expect to be able to ship 23.3 *real soon now*, so we only want to
commit there fixes for regressions now.


        Stefan

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
	7534 <at> debbugs.gnu.org
Subject: Re: bug#7534: what about committing the patch also to emacs-23?
Date: Fri, 4 Feb 2011 16:39:49 +0100

On Fri, Feb 4, 2011 at 15:40, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> Given that the patch for this bug was tiny and inoffensive, what do
>> you think about commiting it also in the emacs-23 branch (before the
>> 23.3 release)?
>
> We expect to be able to ship 23.3 *real soon now*, so we only want to
> commit there fixes for regressions now.
>

mmm... so I've arrived a bit late. It is a pity, because IMO emacs
23.3 would be a little bit better with that bug fixed, but I
understand you.

Thanks anyway.


-- 
Dani Moncayo

Previous Next

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