[Top][All Lists]

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

Re: Brittleness of called-interactively-p

From: Dmitri Paduchikh
Subject: Re: Brittleness of called-interactively-p
Date: Mon, 13 Jul 2015 20:17:50 +0500
User-agent: Gnus/5.13 (Gnus v5.13)

Stefan Monnier <address@hidden> writes:

SM> You might be able to exploit this "ignore non-interactive functions" to
SM> make the current code more robust, indeed.  It might be reasonably easy,
SM> e.g. replace

SM>   (memq (nth 1 frame) '(interactive-p 'byte-code))

SM> with something like (not (commandp (nth 1 frame)).  But note that the
SM> situation for advised functions is still tricky: the outer advice is called
SM> with funcall-interactively (and it interactive) but inner advices and the
SM> original function are always called with `apply' or `funcall' rather
SM> than with funcall-interactively, so called-interactively-p still has to
SM> work harder to try and figure out that "the inner function is actually,
SM> conceptually, called interactively, even though technically it's not".

These calls are internal to the advice mechanism and, of course, they cannot
be considered conceptually interactive. Only the call to the whole advised
function matters if that function is interactive. Other advice-specific
calls should be ignored as well as calls to non-interactive functions. They
can be filtered out, for example, by labelling advice-specific symbols by
special property during advice creation and then checking for this property
inside called-interactively-p. Such symbols as ad-Advice-* are intended to
be used internally by advice only, so ignoring them inside
called-interactively-p should not cause much harm.

reply via email to

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