GNU bug report logs - #18139
24.4.50; called-interactively-p and skip advice:

Previous Next

Package: emacs;

Reported by: raman <raman <at> google.com>

Date: Tue, 29 Jul 2014 01:59:01 UTC

Severity: normal

Tags: unreproducible

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: raman <raman <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Cc: tv.raman.tv <at> gmail.com, emacs-devel <at> gnu.org
Subject: Re: 24.4.50; called-interactively-p and skip advice:
Date: Fri, 01 Aug 2014 09:12:28 -0700
Following up on this  bug with additional info:

I just confirmed that this bug was not present in emacs 24.3 --- where
interactive-p was implemented in C -- that function was declared
obsolete in 23.2.

In 24.4 when we transitioned to nadvice.el is when this appears to have
broken.

Looking at the code in 24.4;

the code for called-interactively-p  and its subsequent call through to 
advice--called-interactively-skip  --- one of the functions placed on
called-interactively-p-functions -- appears to introduce   large level
of complexity. advice--called-interactively-skip is defined in
nadvice.el 

Going back to the specific issue from the Emacspeak side:

What I really need is a way to tell if an interactive command was called
by the user pressing a key e.g. M-f for forward-word -- or M-x
forward-word -- those are the only situations in which the emacspeak
advice that speaks the "current word" should be invoked.  

Using (called-interactively-p 'interactive) for this use-case now that I
look at what that code does feels extremely tangled.

Could we perhaps introduce a C-level variable  -- say "interactivep"
that is exposed to elisp --  code in callint.c could set that variable
appropriately and clear it upon completing command execution. 

At the time nadvice.el was introduced, Stefane had me check through with
emacspeak to make sure that nothing broke -- and I had confirmed it --
admittedly, the current breakage in ruby-mode is caused by a large
number of complex recursive calls that are happening within that mode.

Note that there is only one emacspeak advice invoked even then -- the
one to backward-sexp -- but  the call stack is deep enough that
called-interactively-p gets very confused.

--Raman 




This bug report was last modified 3 years and 346 days ago.

Previous Next


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