bug#20516: 25.0.50; cursor-sensor is not loaded in isearch

bug#20516: 25.0.50; cursor-sensor is not loaded in isearch

[Vitalie Spinu]

Occasionally I am getting

 isearch-cancel: Symbol's value as variable is void: cursor-sensor-inhibit [12 times]

but I cannot give exact steps to reproduce.

Likely cause - isearch is not requiring cursor-sensor.


  Vitalie

bug#20516: 25.0.50; cursor-sensor is not loaded in isearch

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Date: Wed, 06 May 2015 18:44:46 +0200
> 
> Occasionally I am getting
> 
>  isearch-cancel: Symbol's value as variable is void: cursor-sensor-inhibit [12 times]
> 
> but I cannot give exact steps to reproduce.

Can you produce a backtrace?

bug#20516: 25.0.50; cursor-sensor is not loaded in isearch

[Vitalie Spinu]

No I cannot. That's the thing. It happened when I accidentally did
something twisted with isearch from the minibuffer.

I saw this error several times before so I though someone might figure
it out without further input. Next time when it happens I will track
back the key sequence that caused it.

  Vitalie

 >>> Eli Zaretskii on Wed, 06 May 2015 19:54:53 +0300 wrote:

 >> From: Vitalie Spinu <spinuvit@gmail.com>
 >> Date: Wed, 06 May 2015 18:44:46 +0200
 >> 
 >> Occasionally I am getting
 >> 
 >> isearch-cancel: Symbol's value as variable is void: cursor-sensor-inhibit [12 times]
 >> 
 >> but I cannot give exact steps to reproduce.

 > Can you produce a backtrace?

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Kaushal]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

Hi,

Lately, I have been facing this issue in the emacs built from master
branch. I haven't yet seen this error occur on emacs 24.4.

I see it happen now and then and haven't been able to consistently
reproduce it but here is the backtrace. I have not been able to create this
error on "emacs -Q".

I get this error when I am trying to quit isearch. I don't know if this
happens when I try to quit after I tried to search for a term that failed
to be found in the buffer or when I try to quit after a successful search
hit.

But once this started happening, repeated C-g hits keep on throwing this
error and I can't quit isearch.

Then the only way is to restart emacs.

Debugger entered--Lisp error: (void-variable cursor-sensor-inhibit)
  isearch-done(t)
  isearch-cancel()
  isearch-abort()
  funcall-interactively(isearch-abort)
  #<subr call-interactively>(isearch-abort nil nil)
  ad-Advice-call-interactively(#<subr call-interactively> isearch-abort nil
nil)
  apply(ad-Advice-call-interactively #<subr call-interactively>
(isearch-abort nil nil))
  call-interactively(isearch-abort nil nil)
  command-execute(isearch-abort)


In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
 of 2015-05-05 on ...
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Client release 5.10 (Tikanga)

Configured using:
 `configure --prefix=/home/kmodi/usr_local/apps/emacs/master
 CPPFLAGS=-fgnu89-inline'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Minor modes in effect:
  global-auto-complete-mode: t
  minibuffer-line-mode: t
  guide-key-mode: t
  desktop-save-mode: t
  pdf-occur-global-minor-mode: t
  global-anzu-mode: t
  anzu-mode: t
  recentf-mode: t
  winner-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  projectile-global-mode: t
  projectile-mode: t
  global-page-break-lines-mode: t
  keyfreq-autosave-mode: t
  keyfreq-mode: t
  diff-auto-refine-mode: t
  ido-ubiquitous-mode: t
  ido-vertical-mode: t
  flx-ido-mode: t
  global-hungry-delete-mode: t
  hungry-delete-mode: t
  volatile-highlights-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  global-hardcore-mode: t
  hardcore-mode: t
  drag-stuff-global-mode: t
  drag-stuff-mode: t
  ido-everywhere: t
  ace-window-display-mode: t
  global-adaptive-wrap-prefix-mode: t
  adaptive-wrap-prefix-mode: t
  display-time-mode: t
  popwin-mode: t
  which-function-mode: t
  shell-dirtrack-mode: t
  global-modi-mode: t
  modi-mode: t
  override-global-mode: t
  save-place-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  global-eldoc-mode: t
  electric-indent-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
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

[-- Attachment #2: Type: text/html, Size: 4280 bytes --]

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Stefan Monnier]

> I get this error when I am trying to quit isearch. I don't know if this
> happens when I try to quit after I tried to search for a term that failed
> to be found in the buffer or when I try to quit after a successful search
> hit.

Hmmm... I can see 2 ways it could happen:
1- isearch-done is called without having called isearch-mode earlier.
2- isearch-done is called in a different buffer than the one in which
   isearch-mode was called.

I expect you're in case n°2.
Can you think of any reason why you might have started your search in
one buffer and ended it in another?  If not, maybe next time you bump
into it, try to figure what you've done in that search that might have
caused the buffer to be different at the end.

> ad-Advice-call-interactively(#<subr call-interactively> isearch-abort nil nil)

Obligatory side-question: what kind of advice do you have on
call-interactively (in case it might interact in odd ways and ends up
changing the current buffer, for example)?


        Stefan

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Kaushal]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

> Can you think of any reason why you might have started your search in
> one buffer and ended it in another?

I hit C-' by mistake inbetween an isearch while in an org file and that
called `org-cycle-agenda-files` and switched to a different org file while
the search was active.

I tried doing
- C-s
- search something that fails search / search something that has search hits
- C-' (switch to a different org file)
- C-g

But that issue did not occur this time; isearch quit gracefully.

> what kind of advice do you have on
> call-interactively (in case it might interact in odd ways and ends up
> changing the current buffer, for example)?

Doing ag showed me that the ido-ubiquitous.el is advising that:

(defadvice call-interactively (around ido-ubiquitous activate)
  "Implements the behavior specified in `ido-ubiquitous-command-overrides'."
  (let* ((cmd (ad-get-arg 0))
         (override (ido-ubiquitous-get-command-override cmd)))
    (when override
      (ido-ubiquitous--debug-message "Using override `%s' for command `%s'"
                                     override cmd))
    (ido-ubiquitous-with-override override
        ad-do-it)))

I don't understand what it's doing in this advice though.


On Fri, May 8, 2015 at 2:02 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I get this error when I am trying to quit isearch. I don't know if this
> > happens when I try to quit after I tried to search for a term that failed
> > to be found in the buffer or when I try to quit after a successful search
> > hit.
>
> Hmmm... I can see 2 ways it could happen:
> 1- isearch-done is called without having called isearch-mode earlier.
> 2- isearch-done is called in a different buffer than the one in which
>    isearch-mode was called.
>
> I expect you're in case n°2.
> Can you think of any reason why you might have started your search in
> one buffer and ended it in another?  If not, maybe next time you bump
> into it, try to figure what you've done in that search that might have
> caused the buffer to be different at the end.
>
> > ad-Advice-call-interactively(#<subr call-interactively> isearch-abort
> nil nil)
>
> Obligatory side-question: what kind of advice do you have on
> call-interactively (in case it might interact in odd ways and ends up
> changing the current buffer, for example)?
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 5052 bytes --]

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Stefan Monnier]

>> Can you think of any reason why you might have started your search in
>> one buffer and ended it in another?
> I hit C-' by mistake inbetween an isearch while in an org file and that
> called `org-cycle-agenda-files` and switched to a different org file while
> the search was active.

> I tried doing
> - C-s
> - search something that fails search / search something that has search hits
> - C-' (switch to a different org file)
> - C-g

> But that issue did not occur this time; isearch quit gracefully.

Hmm... thanks, I think that will give me enough info for now.

> (defadvice call-interactively (around ido-ubiquitous activate)
>   "Implements the behavior specified in `ido-ubiquitous-command-overrides'."
>   (let* ((cmd (ad-get-arg 0))
>          (override (ido-ubiquitous-get-command-override cmd)))
>     (when override
>       (ido-ubiquitous--debug-message "Using override `%s' for command `%s'"
>                                      override cmd))
>     (ido-ubiquitous-with-override override
>         ad-do-it)))
>
> I don't understand what it's doing in this advice though.

It's kinda nasty, but I think it's not responsible for what you're
seeing,


        Stefan

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Can you think of any reason why you might have started your search in
> one buffer and ended it in another?

This will happen by design if you use isearch to search across multiple
files (i.e. multi-isearch), such as a sequence of ChangeLog.N files.

(There may be other variables than cursor-sensor-inhibit that are also
mishandled in this situation.)

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Stefan Monnier]

>> Can you think of any reason why you might have started your search in
>> one buffer and ended it in another?
> This will happen by design if you use isearch to search across multiple
> files (i.e. multi-isearch), such as a sequence of ChangeLog.N files.

Duh!  Indeed.


        Stefan

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Stefan Monnier]

>> Can you think of any reason why you might have started your search in
>> one buffer and ended it in another?

> This will happen by design if you use isearch to search across multiple
> files (i.e. multi-isearch), such as a sequence of ChangeLog.N files.
> (There may be other variables than cursor-sensor-inhibit that are also
> mishandled in this situation.)

I installed the patch below which should fix this.


        Stefan


diff --git a/lisp/isearch.el b/lisp/isearch.el
index dc10502..5599ea5 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -932,12 +932,6 @@ convert the search string to a regexp used by regexp search functions."
   (add-hook 'post-command-hook 'isearch-post-command-hook)
   (add-hook 'mouse-leave-buffer-hook 'isearch-done)
   (add-hook 'kbd-macro-termination-hook 'isearch-done)
-  (make-local-variable 'cursor-sensor-inhibit)
-  (unless (boundp 'cursor-sensor-inhibit)
-    (setq cursor-sensor-inhibit nil))
-  ;; Suspend things like cursor-intangible during Isearch so we can search even
-  ;; within intangible text.
-  (push 'isearch cursor-sensor-inhibit)
 
   ;; isearch-mode can be made modal (in the sense of not returning to
   ;; the calling function until searching is completed) by entering
@@ -949,10 +943,23 @@ convert the search string to a regexp used by regexp search functions."
 
 
 ;; Some high level utilities.  Others below.
+(defvar isearch--current-buffer)
 
 (defun isearch-update ()
   "This is called after every isearch command to update the display.
 The last thing it does is to run `isearch-update-post-hook'."
+  (unless (eq (current-buffer) isearch--current-buffer)
+    (when isearch--current-buffer
+      (with-current-buffer isearch--current-buffer
+        (setq cursor-sensor-inhibit (delq 'isearch cursor-sensor-inhibit))))
+    (setq isearch--current-buffer (current-buffer))
+    (make-local-variable 'cursor-sensor-inhibit)
+    (unless (boundp 'cursor-sensor-inhibit)
+      (setq cursor-sensor-inhibit nil))
+    ;; Suspend things like cursor-intangible during Isearch so we can search
+    ;; even within intangible text.
+    (push 'isearch cursor-sensor-inhibit))
+
   (if (and (null unread-command-events)
 	   (null executing-kbd-macro))
       (progn
@@ -1026,7 +1033,9 @@ NOPUSH is t and EDIT is t."
   (remove-hook 'mouse-leave-buffer-hook 'isearch-done)
   (remove-hook 'kbd-macro-termination-hook 'isearch-done)
   (setq isearch-lazy-highlight-start nil)
-  (setq cursor-sensor-inhibit (delq 'isearch cursor-sensor-inhibit))
+  (with-current-buffer isearch--current-buffer
+    (setq isearch--current-buffer nil)
+    (setq cursor-sensor-inhibit (delq 'isearch cursor-sensor-inhibit)))
 
   ;; Called by all commands that terminate isearch-mode.
   ;; If NOPUSH is non-nil, we don't push the string on the search ring.

bug#20516: closed (Re: bug#20532: 25.0.50; void-variable cursor-sensor-inhibit)

[Vitalie Spinu]

 >>>  (GNU bug Tracking System)on Wed, 27 May 2015 16:19:03 +0000 wrote:

 >>> Can you think of any reason why you might have started your search in
 >>> one buffer and ended it in another?

 >> This will happen by design if you use isearch to search across multiple
 >> files (i.e. multi-isearch), such as a sequence of ChangeLog.N files.
 >> (There may be other variables than cursor-sensor-inhibit that are also
 >> mishandled in this situation.)

 > I installed the patch below which should fix this.

Thanks, but now you cannot do isearch at all. It simply throws "Symbol's
value as variable is void: isearch--curent-buffer".

BTW, in my case the cause of the problem was indeed switching of buffers
during the isearch, but in it was happening in polymodes when changing
the indirect buffers for different mode chunks.

Strangely enough, after the emacs update of about 2 weeks ago I have
never encountered the problem again. It seems that my problem was fixed
even before the current "fix".


  Vitalie

bug#20516: closed (Re: bug#20532: 25.0.50; void-variable cursor-sensor-inhibit)

[Vitalie Spinu]

 >>> Vitalie Spinu on Wed, 27 May 2015 18:58:14 +0200 wrote:
 > but now you cannot do isearch at all.

I just pulled again, and all is great! Thanks.

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Christoph Ruegge]

This patch causes void-variable errors for me. Shouldn't
isearch--current-buffer have an init value?

bug#20532: 25.0.50; void-variable cursor-sensor-inhibit

[Stefan Monnier]

> This patch causes void-variable errors for me. Shouldn't
> isearch--current-buffer have an init value?

Duh, yes, indeed!


        Stefan