Re: Suggest: dont declare interactive-p obsolete

[Andreas Röhler]

 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
> > > 'interactive))
> > 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
interactively.

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
> spreading.