bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kaushal
Subject: bug#20532: 25.0.50; void-variable cursor-sensor-inhibit
Date: Fri, 08 May 2015 18:10:35 +0000

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]