[Top][All Lists]

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

RE: [External] : Re: Making a function than can only be used interactive

From: carlmarcos
Subject: RE: [External] : Re: Making a function than can only be used interactively
Date: Sat, 9 Jul 2022 00:34:09 +0200 (CEST)

 Sent with Tutanota, enjoy secure & ad-free emails. 

Jul 8, 2022, 22:17 by

>>> Dunno whether it's a coincidence (I'm guessing no),
>>> but in the past couple of weeks there've been a
>>> boatload of similar questions on emacs.SE. Here
>>> are some of them:
>> I saw them and got the same kind of problem of how
>> to write interactive function.
> I can tell - by your just now writing this, even after
> reading my message:
>> I thought that because the prefix argument i[s] used
>> first (using C-u N myfunc) then it also has to be
>> the first argument in the function declaration.
> So you _saw_ my comments on emacs.SE, but it's not
> clear that you _read_ them.
> Do yourself a favor.  Read this  s l o w l y  . . .
>  A "prefix argument" is NOT an argument
>  to the function (command).  It's NOT.
> That is, it _need not be_.  It's _not automatically_
> used as any of the function's args.  It _could_ be
> passed as one or more of the function's args.  There's
> NO necessary or logical connection between the "prefix
> argument" and the function's arguments.
> If this isn't yet clear, please read that again.  And
> again ... till it's clear.
> A prefix argument results from a _user action_.  It
> makes a value available when the function's code is
> evaluated.  If that value isn't passed as one of the
> function's arguments then the function body (or code
> it invokes...) can obtain it using the global variable
> `current-prefix-arg' - see `C-h v current-prefix-arg'.
> And you say:
>> because the prefix argument i[s] used first (using
>> C-u N myfunc)
> No, it's not "used first".  It's _not used at all_
> ... unless the function's code actually, explicitly
> uses it somehow.  A user can hit `C-u' all day long
> with zero effect, if the current command doesn't make
> any use of the prefix arg.
> How can a command (function) explicitly use the prefix
> arg?  (1) in an `interactive' spec, (2) in the body,
> or (3) by passing its value as an argument.
> To use the prefix arg in an `interactive' spec you can
> (1) use `P' or `p' in a string argument (any number of
> times), or (2) use `current-prefix-arg' in a list arg
> (any number of times).
> To use it in the body explicitly, use variable
> `current-prefix-arg'.
> How else can a function use the prefix arg?  (3) Pass
> its value as one or more of the function's args.
>> Quite complicated thing.
> No, not really.  I think you've just been misled by
> the name "prefix ARGUMENT".
> Nothing to be ashamed of.  But now you know - it is
> NOT AN ARGUMENT to the command - not unless (1) the
> command's `interactive' spec provides its value as
> one of the command's arguments OR (2) code that
> invokes the command (function) passes it as one
> of the arguments.
> I don't think any of us have been able to help much
> by replying to vague requests for guidance about
> when to use this or that (optional arg, prefix arg,
> `interactive', ...).
> And the reason, I think, is because the request is
> misguided (an X-Y question).  I'm guessing it's the
> name "prefix argument" that's got you (and perhaps
> others) twisted in a knot by mis-suggesting that it
> represents something that has something to do with
> an argument to the command (function).  IT DOESN'T.
> Now go outside and have fun. ;-)
> ___
> Rereading the Emacs manual about "prefix argument"
> now, I can see where someone might get the wrong
> idea.  It tries to present a command to users as
> something more abstract than the Lisp (or C) function
> that implements it.  And so it talks about a "prefix
> argument" being provided to the command first, and
> "minibuffer args" possibly being provided afterward.
Yes, that was exactly why I had the impression that the list should have
arg storing the prefix argument as the first argument to the function.  And that
it has to be optional because a user can decide not to call the interactive 
with C-u.

> IOW, from a user, non-Lisp point of view, you can
> think that you first provide an "argument" to a
> command using `C-u' etc.  And then the command might
> prompt you for other info ("arguments") in the
> minibuffer.
Yes, I thought that way.

> I think that's what that language is about.  But it
> can (apparently) create a disconnect when someone
> then tries to move to a Lisp understanding, with the
> notion of a command as a function (an interactive
> function), which gets passed arguments.

Correct.  Found it very hard to go from reading to an actual implementation.
I also found no way to get the equivalent of Code Character "P" if the function
 includes an arg that stores the prefix within a list 

For instance

(defun guling (&optional prefix a b)


    ((equal current-prefix-arg 2)
      () ;  What should one put here??? 
      (read-from-minibuffer "a: ")
      (read-from-minibuffer "b: "))))) 


> ___
> [
> NOTE: If some code in a command (in the `interactive'
> spec or in the body), or in any code invoked by the
> command, invokes another command interactively, or lets
> a user invoke another command interactively, then the
> use of that other command invocation redefines the
> `current-prefix-arg' value.
> And yes, _that_ can get a bit complicated.  If you're
> interested in this, and you feel up to it, then dig
> into the Elisp manual, node `Command Loop':
> ]

reply via email to

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