Suggest: dont declare interactive-p obsolete

Suggest: dont declare interactive-p obsolete

[raman]

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))
-- 
we'd lose nothing as far as I can tell, but eliminate  the warning ---
and keep code more readable --
(when  (interactive-p)...)
is arguably more readable than 
(when (called-interactively-p 'interactive) ...)

At present   subr.el defines:

(defun interactive-p ()
  "Return t if the containing function was run directly by user input.
This means that the function was called with `call-interactively'
\(which includes being called as the binding of a key)
and input is currently coming from the keyboard (not a keyboard macro),
and Emacs is not running in batch mode (`noninteractive' is nil).

The only known proper use of `interactive-p' 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 or in batch mode?

To test whether your function was called with `call-interactively',
either (i) add an extra optional argument and give it an `interactive'
spec that specifies non-nil unconditionally (such as \"p\"); or (ii)
use `called-interactively-p'."
  (declare (obsolete called-interactively-p "23.2"))
  (called-interactively-p 'interactive))
-- 

Re: Suggest: dont declare interactive-p obsolete

[John Wiegley]

>>>>> raman  <raman@google.com> 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?

John

Re: Suggest: dont declare interactive-p obsolete

[Artur Malabarba]

2015-11-19 4:16 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
>>>>>> raman  <raman@google.com> 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.
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.

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<jwiegley@gmail.com>:
>>>>>>> raman<raman@google.com>  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.
>

Re: Suggest: dont declare interactive-p obsolete

[Dmitry Gutov]

On 11/19/2015 10:39 AM, Artur Malabarba wrote:

> By my estimates, this function was made obsolete 5 years ago. And it
> _is_ obsolete.
> 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.

+1

Re: Suggest: dont declare interactive-p obsolete

[Dmitry Gutov]

On 11/19/2015 03:06 PM, Andreas Röhler wrote:

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

You're just saying that neither the old, nor the new function should be 
used in most of the Lisp code. That may be true, but that doesn't say 
anything about whether the old name should be un-obsoleted.

Re: Suggest: dont declare interactive-p obsolete

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Wed, 18 Nov 2015 20:16:21 -0800
> Cc: emacs-devel@gnu.org
> 
> >>>>> raman  <raman@google.com> 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?

Because we want to cause Lisp programs not to use it?

There's only a handful of users of this in Emacs -- why not simply
rewrite them to use called-interactively-p?  If we deprecated it, we
should be the first to remove it, no?

I really don't see any reasons to revert our decision because of few
places that need to be cleaned up.

Re: Suggest: dont declare interactive-p obsolete

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> 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?

> Because we want to cause Lisp programs not to use it?

> There's only a handful of users of this in Emacs -- why not simply rewrite
> them to use called-interactively-p? If we deprecated it, we should be the
> first to remove it, no?

> I really don't see any reasons to revert our decision because of few places
> that need to be cleaned up.

OK, let's clean up those places then.

John

Re: Suggest: dont declare interactive-p obsolete

[raman]

Cleaning up those places would be a good first step.

Then we could nuke the definition in subr.el.   At that point, we should
still revisit what the right API to expose for this functionality is --
as  others have pointed out-- the present option

(called-interactively-p 'interactive )

is awkward and hard to discover as an elisp developer -- and even if you
discovered it -- you'd run screaming in fear.  

The  net/net of the documentation of called-interactively-p is that you
should essentially only use it as (called-interactively-p
'interactive) -- if that is our intent -- why not provide that as a
high-level call?

Let me make it clear -- I'm not asking for this because any o fmy own
code /libs depend on this -- they dont -- for the record,
called-interactively-p as implemented does not work in any form  for my
own use-cases:-)
-- 

Re: Suggest: dont declare interactive-p obsolete

[Eli Zaretskii]

> From: raman <raman@google.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Nov 2015 09:32:29 -0800
> 
> Cleaning up those places would be a good first step.
> 
> Then we could nuke the definition in subr.el.

We need to announce that first.  So it probably won't happen in Emacs
25.1.

> At that point, we should still revisit what the right API to expose
> for this functionality is -- as others have pointed out-- the
> present option
> 
> (called-interactively-p 'interactive )
> 
> is awkward and hard to discover as an elisp developer -- and even if you
> discovered it -- you'd run screaming in fear.  

We could work on improving this situation regardless of what happens
with interactive-p, and when.  We could start right now.

Thanks.

Re: Suggest: dont declare interactive-p obsolete

[Andreas Röhler]

  On 19.11.2015 14:46, Dmitry Gutov wrote:
> On 11/19/2015 03:06 PM, Andreas Röhler wrote:
>
>> 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)).
>
> You're just saying that neither the old, nor the new function should 
> be used in most of the Lisp code. That may be true, but that doesn't 
> say anything about whether the old name should be un-obsoleted.

That's not me saying this, that's the docstring of current implementation.