locate-library INTERACTIVE-CALL argument

locate-library INTERACTIVE-CALL argument

[Kevin Rodgers]

locate-library's optional INTERACTIVE-CALL argument is completely unnecessary
given the interactive-p function, and no calls in the 21.3 source specify it.

Here's a patch (based on the original source, not my previous patch that
provides a default LIBRARY value):

*** emacs-21.3/lisp/help.el.orig	Thu Sep  5 16:47:16 2002
--- emacs-21.3/lisp/help.el	Thu Jul 31 10:36:45 2003
***************
*** 1023,1029 ****
   	(princ (format "%s is not on any key" definition)))))
     nil)

! (defun locate-library (library &optional nosuffix path interactive-call)
     "Show the precise file name of Emacs library LIBRARY.
   This command searches the directories in `load-path' like `M-x load-library'
   to find the file that `M-x load-library RET LIBRARY RET' would load.
--- 1023,1029 ----
   	(princ (format "%s is not on any key" definition)))))
     nil)

! (defun locate-library (library &optional nosuffix path)
     "Show the precise file name of Emacs library LIBRARY.
   This command searches the directories in `load-path' like `M-x load-library'
   to find the file that `M-x load-library RET LIBRARY RET' would load.
***************
*** 1033,1044 ****
   If the optional third arg PATH is specified, that list of directories
   is used instead of `load-path'.

! When called from a program, the file name is normaly returned as a
! string.  When run interactively, the argument INTERACTIVE-CALL is t,
! and the file name is displayed in the echo area."
     (interactive (list (read-string "Locate library: ")
! 		     nil nil
! 		     t))
     (let (result)
       (catch 'answer
         (mapc
--- 1033,1042 ----
   If the optional third arg PATH is specified, that list of directories
   is used instead of `load-path'.

! When called from a program, the file name is normaly returned as a string.
! When run interactively, the file name is displayed in the echo area."
     (interactive (list (read-string "Locate library: ")
! 		     nil nil))
     (let (result)
       (catch 'answer
         (mapc
***************
*** 1068,1074 ****
   		 
	 compressed))
   		basic)))))
          (or path load-path)))
!     (and interactive-call
   	 (if result
   	     (message "Library is file %s" result)
   	   (message "No library %s in search path" library)))
--- 1066,1072 ----
   		 
	 compressed))
   		basic)))))
          (or path load-path)))
!     (and (interactive-p)
   	 (if result
   	     (message "Library is file %s" result)
   	   (message "No library %s in search path" library)))

-- 
Kevin Rodgers

Re: locate-library INTERACTIVE-CALL argument

[Richard Stallman]

Using interactive-p is not equivalent to what the INTERACTIVE-CALL
argument does.  So the change is not a no-op.  The effect of the change
would be not to output anything if used in a keyboard macro.  This is
explained in the Lisp Manual.

I don't think that change would be an improvement here.

Re: locate-library INTERACTIVE-CALL argument

[Kevin Rodgers]

Richard Stallman wrote:

 > Using interactive-p is not equivalent to what the INTERACTIVE-CALL
 > argument does.  So the change is not a no-op.  The effect of the change
 > would be not to output anything if used in a keyboard macro.  This is
 > explained in the Lisp Manual.

Thanks for pointing that out.  But I'm still not happy with the current
implementation.  If the command is called interactively (within a
keyboard macro or not), INTERACTIVE-CALL is unconditionally set to t, so
the message will displayed.  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?

-- 
Kevin Rodgers

Re: locate-library INTERACTIVE-CALL argument

[Richard Stallman]

    Thanks for pointing that out.  But I'm still not happy with the current
    implementation.  If the command is called interactively (within a
    keyboard macro or not), INTERACTIVE-CALL is unconditionally set to t, so
    the message will displayed.

That is correct.

				 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.

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.

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

Re: locate-library INTERACTIVE-CALL argument

[Richard Stallman]

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

I was thinking of the former, but the latter might be a good idea.

    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.

The `interactive' form, when evaluated, returns nil.
However, it holds one "argument", a form that can be evaluated
to produce a list of argument values.  It could hold additional
"arguments" which could be used for various purposes,
including to display the command's return value.