emacs-devel
[Top][All Lists]
Advanced

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

RE: interactive-p and called-interactively-p


From: Drew Adams
Subject: RE: interactive-p and called-interactively-p
Date: Sun, 16 Aug 2009 15:40:28 -0700

>     > It would have been far better to just add an optional 
>     > argument to `interactive-p' than to create a new,
>     > similarly named function.
> 
>     Agreed.  Any objection?
> 
> I object.  Two different names makes it easier to remember the
> difference.

That might be true, IF the names in question actually suggested the difference.

But you can understand nothing of the difference by looking at these particular
function names. All you can tell is that they are different functions (duh), but
with names that seem to say the same thing (huh?).

To understand the difference, you must then compare two doc strings that are
very similar, looking for a difference. Or read the manual and compare the
descriptions there.

In either case, the work you need to do to understand the difference is far more
than what is needed to understand what the optional arg K-MACRO-P does.

(And that's probably at least partly behind why the current doc for these is
almost incomprehensible and not entirely correct.)

> An argument would be harder to remember.

Harder to remember what, that there ARE two possible behaviors? Or WHAT those
behaviors are? This is what arguments are all about - the basic function is the
same, but its behavior depends a bit on its args.

In this case, the function names do NOT help you remember WHAT the difference
is. (The doc can't even seem to get it right.)

Having a single function with its alternative behaviors described in terms of an
optional arg is much clearer. And even seeing just the signature (with
`&optional K-MACRO-P') clarifies the meaning and helps remembering - it's
obvious from just the signature that the behavior difference is about keyboard
macros.

The most important thing to "remember" about these two functions is in fact that
they do essentially the SAME thing. They differ only in the K-MACRO-P aspect.
The basic function is the same.

So first you have to know that there are two such functions, and then you have
to look them both up, to be sure to get the right one. 

If you only know about one of the functions (I'll bet that that's the case today
for many Elisp programmers), then you risk using the wrong one (the only one you
know). If you know there are two, you still need to look them both up, to recall
which is which.

> The name `called-interactively-p' is good because
> it relates to the use of `interactive'.  The name `interactive-p'
> is confusing because it does NOT relate.

I'm not convinced, but I have no problem with that: deprecate `interactive-p' in
that case.

> Perhaps we should make the name `interactive-p' obsolete
> and make a new name, `from-user-input-p'.  This will eliminate
> the confusion completely.

OK with making one of the two functions (or both) obsolete. I don't really care
what name is retained for the merged function. 

FWIW - Of the 3 names mentioned here, my own preference would probably be first
`interactive-p', then `called-interactively-p', and last `from-user-input-p'
(not very helpful, IMO).

But I have no problem with any name that suggests what this does in a general
way. For me, the basic function it performs is to test whether the current
invocation was made interactively.

[Yes, that means invoked via `call-interactively', which is why
`called-interactively-p' is not bad. But we have already seen some confusion
surrounding `called-interactively-p' and `call-interactively'.

`interactive-p' is better in a sense, because it is higher level. Some users
might not realize that interactive invocation always means invocation through
`call-interactively', even when `call-interactively' might not appear explicitly
in the Lisp source code.

A name such as `invoked-interactively-p', which of course means the same thing
as `called-interactively-p', doesn't lend itself to such confusion.

(Of course, introducing a third name at this point does imply even more
adjustment of existing code.)]





reply via email to

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