bug#7468: 24.0.50; Isearch highlighting

bug#7468: 24.0.50; Isearch highlighting

[Dani Moncayo]

Hello,

I think I've found one (strange) situation where Isearch highlighting
doesn't seem to work well.

Steps to reproduce:
 0) Start emacs (emacs -Q).
 1) Open Emacs Manual (C-h r)
 2) Go to node "(emacs)Error in Isearch" (g Error <TAB> <RET>)
 3) Search for the word "foott" (C-s foott)
 4) Remove the las "t" (<DEL>)

** Expected result: The last 3 occurrences of the word "foot" are
highlighted again with the `lazy-highlight' face.
** Actual result: Those 3 words don't get highlighted at all.

I've also tried to copy that section of the manual into a brand new
buffer, but there I can't reproduce the problem.

-- 
Dani Moncayo


In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0)
 of 2010-11-19 on dani-P5PL2
Windowing system distributor `The X.Org Foundation', version 11.0.10900000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: es_ES.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

bug#7468: 24.0.50; Isearch highlighting

[Juri Linkov]

> I've also tried to copy that section of the manual into a brand new
> buffer, but there I can't reproduce the problem.

The difference between this recipe in a normal buffer and an Info buffer
is in the line

    (when (not isearch-error)

in `isearch-lazy-highlight-new-loop'.  A normal Isearch starts
a new lazy highlighting loop even if there are no matches,
so it has a chance to set `isearch-lazy-highlight-last-string'.
But an Isearch in Info has the text "Initial node" in `isearch-error',
so `isearch-lazy-highlight-new-loop' doesn't set the last search string
to `isearch-lazy-highlight-last-string'.

This bug is not specific to an Isearch in Info.  You can get the same bug
for a regexp Isearch in a normal buffer as:

1) Search for the regexp "foot[" (C-M-s foot[)
2) Remove the last "[" (<DEL>)

There is no lazy highlighting too.

I think this patch is a general fix for all these bug cases:

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2010-10-02 22:37:21 +0000
+++ lisp/isearch.el	2010-11-23 01:30:44 +0000
@@ -2628,6 +2628,7 @@ (defvar isearch-lazy-highlight-case-fold
 (defvar isearch-lazy-highlight-regexp nil)
 (defvar isearch-lazy-highlight-space-regexp nil)
 (defvar isearch-lazy-highlight-forward nil)
+(defvar isearch-lazy-highlight-error nil)
 
 (defun lazy-highlight-cleanup (&optional force)
   "Stop lazy highlighting and remove extra highlighting from current buffer.
@@ -2669,9 +2670,12 @@ (defun isearch-lazy-highlight-new-loop (
                  (not (= (window-end)   ; Window may have been split/joined.
 			 isearch-lazy-highlight-window-end))
 		 (not (eq isearch-forward
-			  isearch-lazy-highlight-forward))))
+			  isearch-lazy-highlight-forward))
+		 (not (eq isearch-error
+			  isearch-lazy-highlight-error))))
     ;; something important did indeed change
     (lazy-highlight-cleanup t) ;kill old loop & remove overlays
+    (setq isearch-lazy-highlight-error isearch-error)
     (when (not isearch-error)
       (setq isearch-lazy-highlight-start-limit beg
 	    isearch-lazy-highlight-end-limit end)

bug#7468: 24.0.50; Isearch highlighting

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> This bug is not specific to an Isearch in Info.  You can get the same bug
> for a regexp Isearch in a normal buffer as:
>
> 1) Search for the regexp "foot[" (C-M-s foot[)
> 2) Remove the last "[" (<DEL>)
>
> There is no lazy highlighting too.
>
> I think this patch is a general fix for all these bug cases:

Looks good to me, could you commit it to the emacs-23 branch?  Thanks.

bug#7468: 24.0.50; Isearch highlighting

[Juri Linkov]

> Looks good to me, could you commit it to the emacs-23 branch?  Thanks.

Ok, will do when bzr.savannah.gnu.org will be available.  Currently bzr says:

  Unable to connect to SSH host bzr.savannah.gnu.org; EOF during negotiation

bug#7468: 24.0.50; Isearch highlighting

[Dani Moncayo]

On Sun, Dec 5, 2010 at 23:59, Juri Linkov <juri@jurta.org> wrote:
>> Looks good to me, could you commit it to the emacs-23 branch?  Thanks.
>
> Ok, will do when bzr.savannah.gnu.org will be available.  Currently bzr says:
>
>  Unable to connect to SSH host bzr.savannah.gnu.org; EOF during negotiation
>

ping

-- 
Dani Moncayo

bug#7468: 24.0.50; Isearch highlighting

[Chong Yidong]

Dani Moncayo <dmoncayo@gmail.com> writes:

> On Sun, Dec 5, 2010 at 23:59, Juri Linkov <juri@jurta.org> wrote:
>>> Looks good to me, could you commit it to the emacs-23 branch?  Thanks.
>>
>> Ok, will do when bzr.savannah.gnu.org will be available.  Currently bzr says:
>>
>> Unable to connect to SSH host bzr.savannah.gnu.org; EOF during negotiation
>>
>
> ping

Bzr seems to be working fine for me.  Juri, you still having problems
connecting?

bug#7468: 24.0.50; Isearch highlighting

[Juri Linkov]

>>>> Looks good to me, could you commit it to the emacs-23 branch?  Thanks.
>>>
>>> Ok, will do when bzr.savannah.gnu.org will be available.  Currently bzr says:
>>> Unable to connect to SSH host bzr.savannah.gnu.org; EOF during negotiation
>>
>> ping
>
> Bzr seems to be working fine for me.  Juri, you still having problems
> connecting?

Perhaps there is some misconfiguration on my side. `.bzr.log' says:

  Unable to obtain credentials for {'protocol': 'ssh', 'server': 'bzr.savannah.gnu.org'}
  from GNOME keyring: NoMatchError()

but from the command line I still can ssh to bzr.savannah.gnu.org
(that says "VCS commands are allowed").  I'll investigate now what is wrong.

bug#7468: 24.0.50; Isearch highlighting

[Juri Linkov]

>> I think this patch is a general fix for all these bug cases:
>
> Looks good to me, could you commit it to the emacs-23 branch?  Thanks.

Done.  Sorry for the delay.