Re: locate-library INTERACTIVE-CALL argument

[Kevin Rodgers]

Richard Stallman wrote:

> > Since the intent is to display the message
> > when the command is called interactively, even when it is called via a
> > keyboard macro, why not test for those conditions explicitly with
> > interactive-p and executing-macro respectively?
>
> There is no way to do that and get the same condition.
> (or (interactive-p) executing-macro) would be t
> when called from Lisp code that was run by a keyboard macro.
>
> Perhaps there ought to be a way to use interactive-p to get
> such a result.  It could be a good feature.


Do you mean adding an &optional KEYBOARD-MACROS-TOO argument, so it

would return non-nil even when called while executing a keyboard macro?

Or do you mean distinguishing different non-nil return values, e.g.
call-interactively vs. execute-kbd-macro (instead of just t)?


> But there may be a better feature.  Ever since 1985 I had the idea
> that maybe (interactive...)  could be extended with a second argument
> saying how to display the value.  That would be complimentary with the
> existing arg saying how to provide the arguments.  That might be the
> really clean way to do this job.

I don't know what you mean.  (interactive ...) returns a list of values,

which are mapped to the lambda list symbols.  Do you mean that it would
accept an &optional KEYBOARD-MACROS-TOO argument, which would determine
what interactive-p returns while executing a keyboard macro?


If so, I think adding an &optional argument to interactive-p is cleaner,
since it's "closer" to the desired effect than adding one to interactive.

Maybe an example would be helpful.  The question is, given a command foo
that usually displays a message when called interactively, how to allow
the Emacs Lisp programmer to control whether that messsage is displayed
in these different contexts:

1. C-x ( ... M-x foo RET ... C-x )

   should obviously display the message.

2. C-x ( ... M-: (foo ...) RET ... C-x )

   should not.

--
Kevin Rodgers