GNU bug report logs - #20532
25.0.50; void-variable cursor-sensor-inhibit

Previous Next

Full log

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

From: Kaushal <kaushal.modi <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20532 <at> debbugs.gnu.org
Subject: Re: bug#20532: 25.0.50; void-variable cursor-sensor-inhibit
Date: Fri, 08 May 2015 18:10:35 +0000

[Message part 1 (text/plain, inline)]

> 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 <at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

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