[Top][All Lists]

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

Re: Suggest: dont declare interactive-p obsolete

From: Andreas Röhler
Subject: Re: Suggest: dont declare interactive-p obsolete
Date: Thu, 19 Nov 2015 14:06:21 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.1.4

 On 19.11.2015 09:39, Artur Malabarba wrote:
2015-11-19 4:16 GMT+00:00 John Wiegley<address@hidden>:
raman<address@hidden>  writes:
This is a minor change -- that will let existing code run without warnings.
If we turned the defun in subr.el to a defsubst and dropped the (declare
(obsolete called-interactively-p "23.2")) (called-interactively-p
I don't see any downsides to this; others?
I wasn't here when this function was made obsolete, but I can think of
a couple of downsides:

1. Code duplication (sure, the code is already duplicated, but by
keeping it obsolete we can hopefully remove it soon).
2. The name interactive-p makes it sound like it's equivalent to `(not
noninteractive)', which determines whether Emacs itself (not the
function) is running interactively. While `called-interactively-p' is
more obviously about how the function was called.

By my estimates, this function was made obsolete 5 years ago. And it
_is_ obsolete.

Don't think so. Its replacement is not only hard to code, it's a monster.
The docu says all:

Return t if the containing function was called by `call-interactively'.
If KIND is `interactive', then only return t if the call was made
interactively by the user, i.e. not in `noninteractive' mode nor
when `executing-kbd-macro'.
If KIND is `any', on the other hand, it will return t for any kind of
interactive call, including being called as the binding of a key or
from a keyboard macro, even in `noninteractive' mode.

This function is very brittle, it may fail to return the intended result when
the code is debugged, advised, or instrumented in some form.  Some macros and
special forms (such as `condition-case') may also sometimes wrap their bodies
in a `lambda', so any call to `called-interactively-p' from those bodies will
indicate whether that lambda (rather than the surrounding function) was called

Instead of using this function, it is cleaner and more reliable to give your
function an extra optional argument whose `interactive' spec specifies
non-nil unconditionally (\"p\" is a good way to do this), or via
\(not (or executing-kbd-macro noninteractive)).

The only known proper use of `interactive' for KIND is in deciding
whether to display a helpful message, or how to display it.  If you're
thinking of using it for any other purpose, it is quite likely that
you're making a mistake.  Think: what do you want to do when the
command is called from a keyboard macro?

IMHO, packages that try to support Emacs releases 6 years apart (as
noble as that is) can't expect to be able to do that without a few
warnings. There are ways for such packages to suppress these warnings.
But it's important to keep them to prevent this function from

reply via email to

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