Placement of list within an interactive clause

Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

I am writing an interactive function and encountering a difficulty on the placing of the command `list' to set the function argument.  

Is it most sensible to call `list' first after `interactive', followed by `let' ?

Or use `let' first, with `list' appearing in the body of the `let' clause ?

Does it make difference where the list statement is placed?


This code
  (interactive   (list    (let ( (rqmatch t)  (initpk "mixed")  (dflt "extended")           (cseq '("expression" "mixed" "hlsexp"                      "bracemk" "extended" "disable")) )      (completing-read "Flare_type: " cseq nil rqmatch initpk         'flare-hist dflt))))

versus the following

  (interactive    (let ( (rqmatch t)  (initpk "mixed")  (dflt "extended")       (cseq '("expression" "mixed" "hlsexp"                     "bracemk" "extended" "disable")) )      (list          (completing-read "Flare_type: " cseq nil rqmatch initpk            'flare-hist dflt))))

Re: Placement of list within an interactive clause

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Does it make difference where the list statement is placed?

Write the code the way you find most convenient.
The syntax is:

    (defun FOO (...)
      (interactive EXP)
      ...)

where EXP is *any* code whose evaluation returns a list of values.

In that case an interactive call to FOO will behave like (apply #'FOO EXP)


        Stefan

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 18:34 by help-gnu-emacs@gnu.org:

>> Does it make difference where the list statement is placed?
>>
>
> Write the code the way you find most convenient.
> The syntax is:
>
>  (defun FOO (...)
>  (interactive EXP)
>  ...)
>
> where EXP is *any* code whose evaluation returns a list of values.
>
> In that case an interactive call to FOO will behave like (apply #'FOO EXP)
>
>  Stefan
>

When using ` (interactive (list (if condition (body))))', would the commands in the body of the if statement form part of the list? Does the same apply if using ` (let ' instead of ` (if ', where the body be part of the list entries?

Re: Placement of list within an interactive clause

[Philip Kaludercic]

carlmarcos--- via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Jul 14, 2022, 18:34 by help-gnu-emacs@gnu.org:
>
>>> Does it make difference where the list statement is placed?
>>>
>>
>> Write the code the way you find most convenient.
>> The syntax is:
>>
>>  (defun FOO (...)
>>  (interactive EXP)
>>  ...)
>>
>> where EXP is *any* code whose evaluation returns a list of values.
>>
>> In that case an interactive call to FOO will behave like (apply #'FOO EXP)
>>
>>  Stefan
>>
>
> When using ` (interactive (list (if condition (body))))', would the
> commands in the body of the if statement form part of the list? Does
> the same apply if using ` (let ' instead of ` (if ', where the body be
> part of the list entries?

The interactive expression evaluates to a list that is applied to the
function.  So when you see

--8<---------------cut here---------------start------------->8---
(defun foo (...)
  (interactive (list arg1 arg2 ... argn))
  ...)
--8<---------------cut here---------------end--------------->8---

you can think imagine that an interactive call does

--8<---------------cut here---------------start------------->8---
(apply #'foo (list arg1 arg2 ... argn))
--8<---------------cut here---------------end--------------->8---

Re: Placement of list within an interactive clause

[Stefan Monnier via Users list for the GNU Emacs text editor]

> When using ` (interactive (list (if condition (body))))', would the commands
> in the body of the if statement form part of the list? Does the same apply

I think you're jumping ahead of yourself because you don't seem to have
a good grasp of how Lisp works (this question has nothing to do with
`interactive`).

Commands don't "form part" of lists.  Lists contain values (and are
themselves values) and commands manipulate (and return) values when
they're evaluated.

Maybe going through the "Introduction to Emacs Lisp" (see "Help => More
Manual => Introduction to Emacs Lisp" in the menu) will be helpful.


        Stefan

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 20:30 by help-gnu-emacs@gnu.org:

>> When using ` (interactive (list (if condition (body))))', would the commands
>> in the body of the if statement form part of the list? Does the same apply
>>
>
> I think you're jumping ahead of yourself because you don't seem to have
> a good grasp of how Lisp works (this question has nothing to do with
> `interactive`).
>
> Commands don't "form part" of lists.  Lists contain values (and are
> themselves values) and commands manipulate (and return) values when
> they're evaluated.
>
My question was about how I can determine which parts are used to fill elements to the list.
Whether it is from the body of `if' and `let' clauses.  Perhaps I was not so articulate in the choice of words.


> Maybe going through the "Introduction to Emacs Lisp" (see "Help => More
> Manual => Introduction to Emacs Lisp" in the menu) will be helpful.
>
>
>  Stefan
>

Re: Placement of list within an interactive clause

[Stefan Monnier]

carlmarcos@tutanota.com [2022-07-14 22:52:43] wrote:
> My question was about how I can determine which parts are used to fill
> elements to the list.  Whether it is from the body of `if' and `let'
> clauses.  Perhaps I was not so articulate in the choice of words.

And my answer is that the expression returns a list and the origin of
each part of the list is determined by the general semantics of Emacs
Lisp (which is basically the same as that of all other programming
languages in this respect).


        Stefan

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 21:12 by monnier@iro.umontreal.ca:

> carlmarcos@tutanota.com [2022-07-14 22:52:43] wrote:
>
>> My question was about how I can determine which parts are used to fill
>> elements to the list.  Whether it is from the body of `if' and `let'
>> clauses.  Perhaps I was not so articulate in the choice of words.
>>
>
> And my answer is that the expression returns a list and the origin of
> each part of the list is determined by the general semantics of Emacs
> Lisp (which is basically the same as that of all other programming
> languages in this respect).
>
>  Stefan
>
Got it.

RE: [External] : Re: Placement of list within an interactive clause

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

> I think you're jumping ahead of yourself because you don't seem to have
> a good grasp of how Lisp works (this question has nothing to do with
> `interactive`).

Indeed; this has been pointed out to OP.

> Maybe going through the "Introduction to Emacs Lisp" (see "Help => More
> Manual => Introduction to Emacs Lisp" in the menu) will be helpful.

And that too has been suggested to OP.



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13612 bytes --]

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 20:30 by help-gnu-emacs@gnu.org:

>> When using ` (interactive (list (if condition (body))))', would the commands
>> in the body of the if statement form part of the list? Does the same apply
>>
>
> I think you're jumping ahead of yourself because you don't seem to have
> a good grasp of how Lisp works (this question has nothing to do with
> `interactive`).
>
> Commands don't "form part" of lists.  Lists contain values (and are
> themselves values) and commands manipulate (and return) values when
> they're evaluated.
>
> Maybe going through the "Introduction to Emacs Lisp" (see "Help => More
> Manual => Introduction to Emacs Lisp" in the menu) will be helpful.
>
>  Stefan
>
Can you make clear what sections should I read to answer my question?

RE: [External] : Re: Placement of list within an interactive clause

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

> > Maybe going through the "Introduction to Emacs Lisp" (see "Help =>
> > More Manual => Introduction to Emacs Lisp" in the menu) will be helpful.
>
> Can you make clear what sections should I read to answer my question?

<unsolicited-advice>

Please understand that you don't have one question.
You have 8 zillion.  Nothing wrong with having lots
of questions.  But many that you have would be
answered by reading some of that manual - I'm sure
of that - 100%.

It's an "introduction".  It starts at the beginning.
And that's where _you_ should start, for maximum
benefit.

It may seem easier to toss every question over the
fence without a basic understanding.  But sooner or
later you might find that the answers you get may
be thinner and thinner.

More preparation usually gets rewarded with better
questions and then better answers.  The best thing
you can do to help yourself is to learn to Ask Emacs.

Asking Emacs includes taking advantage of its
documentation - just as much as its communities
here & there.

The manuals come with good indexes - use `i' (with
completion).  You're looking for info about `list',
it sounds like.  Make friends with `i'.  You'll
still have friends here, and you may even be more
likely to keep them. ;-)

Other than `i', you're shown the Table of Contents
at the outset.  The VERY FIRST topic in the TOC,
after `Preface', is `List Processing'.  Sound like
a good place to start?  Click it...

1 List Processing
*****************

To the untutored eye, Lisp is a strange programming language.  In Lisp
code there are parentheses everywhere.  Some people even claim that the
name stands for “Lots of Isolated Silly Parentheses”.  But the claim is
unwarranted.  Lisp stands for LISt Processing, and the programming
language handles _lists_ (and lists of lists) by putting them between
parentheses.  The parentheses mark the boundaries of the list.
Sometimes a list is preceded by an apostrophe ‘'’, called a
“single-quote” in Lisp.(1)  Lists are the basis of Lisp.

* Menu:

* Lisp Lists::                  What are lists?
* Run a Program::               Any list in Lisp is a program ready to run.
* Making Errors::               Generating an error message.
* Names & Definitions::         Names of symbols and function definitions.
* Lisp Interpreter::            What the Lisp interpreter does.
* Evaluation::                  Running a program.
* Variables::                   Returning a value from a variable.
* Arguments::                   Passing information to a function.
* set & setq::                  Setting the value of a variable.
* Summary::                     The major points.
* Error Message Exercises::

</unsolicited-advice>

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14828 bytes --]

Re: Placement of list within an interactive clause

[Jean Louis]

Most of time I do not use `interactive' for supply arguments to
function.

Thus instead of following:

(defun my-fun-1 (&optional name)
  (interactive "MName: ")
  (message "Hello %s" name))

I am using following:

(defun my-fun-2 (&optional name)
  (interactive)
  (let ((name (or name (read-from-minibuffer "Name: "))))
    (message "Hello %s" name)))

as that gives me little more freedom:

- if I call (my-fun-1) ⇒ "Hello nil" that result is not what I
 really want. It makes it difficult to get the wanted result. To
 get the wanted result I need to use:

(call-interactively 'my-fun-1) ⇒ "Hello Bob"

- but if I call (my-fun-2) and NAME is not supplied, I will be
  asked for name: (my-fun-2) ⇒ "Hello Bob" and will not get "NIL"
  as result. In this case I need not complicate the call and use
`call-interactively`.

Additionall, complex `interactive` clauses I find often too
difficult to comprehend than reading the body of the function.

Fo this reason I recommend using this second approach with (or
ARGUMENT (GET-ARGUMENT)) rather then using `interactive` with
purpose to supply arguments.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[Christopher Dimech]

> Sent: Friday, July 15, 2022 at 7:26 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: carlmarcos@tutanota.com
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Placement of list within an interactive clause
>
> Most of time I do not use `interactive' for supply arguments to
> function.
> 
> Thus instead of following:
> 
> (defun my-fun-1 (&optional name)
>   (interactive "MName: ")
>   (message "Hello %s" name))
> 
> I am using following:
> 
> (defun my-fun-2 (&optional name)
>   (interactive)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))
> 
> as that gives me little more freedom:
> 
> - if I call (my-fun-1) ⇒ "Hello nil" that result is not what I
>  really want. It makes it difficult to get the wanted result. To
>  get the wanted result I need to use:
> 
> (call-interactively 'my-fun-1) ⇒ "Hello Bob"
> 
> - but if I call (my-fun-2) and NAME is not supplied, I will be
>   asked for name: (my-fun-2) ⇒ "Hello Bob" and will not get "NIL"
>   as result. In this case I need not complicate the call and use
> `call-interactively`.
> 
> Additionall, complex `interactive` clauses I find often too
> difficult to comprehend than reading the body of the function.

Yes, but you are forced for interactive commands.  It is not equivalent
to a function that is non-interactive.
 
> Fo this reason I recommend using this second approach with (or
> ARGUMENT (GET-ARGUMENT)) rather then using `interactive` with
> purpose to supply arguments.
> 
> 
> -- 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
>

Re: Placement of list within an interactive clause

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-07-15 11:19]:
> > Thus instead of following:
> > 
> > (defun my-fun-1 (&optional name)
> >   (interactive "MName: ")
> >   (message "Hello %s" name))
> > 
> > I am using following:
> > 
> > (defun my-fun-2 (&optional name)
> >   (interactive)
> >   (let ((name (or name (read-from-minibuffer "Name: "))))
> >     (message "Hello %s" name)))
> > 
> > as that gives me little more freedom:
> > 
> > - if I call (my-fun-1) ⇒ "Hello nil" that result is not what I
> >  really want. It makes it difficult to get the wanted result. To
> >  get the wanted result I need to use:
> > 
> > (call-interactively 'my-fun-1) ⇒ "Hello Bob"
> > 
> > - but if I call (my-fun-2) and NAME is not supplied, I will be
> >   asked for name: (my-fun-2) ⇒ "Hello Bob" and will not get "NIL"
> >   as result. In this case I need not complicate the call and use
> > `call-interactively`.
> > 
> > Additionall, complex `interactive` clauses I find often too
> > difficult to comprehend than reading the body of the function.
> 
> Yes, but you are forced for interactive commands.  It is not equivalent
> to a function that is non-interactive.

You are not forced to supply arguments within (interactive), not at
all. Function may not need any arguments. But if it has prefix you
should declare (interactive "P"). But if it needs some text input you
may say (interactive "MInput: ")

However, I have explained in the above example of mine that such input
may be provided in the function itself. And it looks to me that it is
better handled that way than through `interactive' declaration.

So this is the way to go:

(defun my-fun-2 (&optional name)
  (interactive)
  (let ((name (or name (read-from-minibuffer "Name: "))))
    (message "Hello %s" name)))

Function `interactive' DOES NOT make function "interactive" in the
other contexts in English language, there is special meaning in the
Emacs Lisp context. Programming meaning is simply not same to English
context.

To call function interactively, it means not to call it exclusively
from Lisp, but from the user interface by using M-x or key. 

That means, when there is declaration (interactive), that function
becomes accessible through M-x invokation, and it may be bound to a
key. 

It means then you can run the function by pressing a key (that is what
is meant with "interactively") or by invoking the function with M-x
or through menus.

IT DOES NOT EXCLUDE that other functions without the declaration
"(interactive)" are and can be "interactive" in the meaning of English
language.

You may thus have a function that is command and that may be invoked
interactively because of declaration "(interactive)":

(defun my-fun-2 (&optional name)
  (interactive)
  (let ((name (or name (read-from-minibuffer "Name: "))))
    (message "Hello %s" name)))

And you may have interactive function, that interacts with user
without declaration "(interactive)":

(defun my-fun-3 (&optional name)
  (let ((name (or name (read-from-minibuffer "Name: "))))
    (message "Hello %s" name)))

And that function in the meaning of English language is interactive,
but is not a command in the meaning of Emacs Lisp because it does not
have declaration "(interactive)".


,----
| Specify a way of parsing arguments for interactive use of a function.
| For example, write
|  (defun foo (arg buf) "Doc string" (interactive "P\nbbuffer: ") .... )
|  to make ARG be the raw prefix argument, and set BUF to an existing buffer,
|  when ‘foo’ is called as a command.
| 
| The "call" to ‘interactive’ is actually a declaration rather than a
|  function; it tells ‘call-interactively’ how to read arguments to pass
|  to the function.  When actually called, ‘interactive’ just returns
|  nil.
| 
| Usually the argument of ‘interactive’ is a string containing a code
|  letter followed optionally by a prompt.  (Some code letters do not
|  use I/O to get the argument and do not use prompts.)  To pass several
|  arguments to the command, concatenate the individual strings,
|  separating them by newline characters.
| 
| Prompts are passed to ‘format’, and may use %s escapes to print the
|  arguments that have already been read.
| 
| If the argument is not a string, it is evaluated to get a list of
|  arguments to pass to the command.
| 
| Just ‘(interactive)’ means pass no arguments to the command when
|  calling interactively.
`----


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[Christopher Dimech]

> Sent: Friday, July 15, 2022 at 10:14 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: carlmarcos@tutanota.com, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Placement of list within an interactive clause
>
> * Christopher Dimech <dimech@gmx.com> [2022-07-15 11:19]:
> > > Thus instead of following:
> > > 
> > > (defun my-fun-1 (&optional name)
> > >   (interactive "MName: ")
> > >   (message "Hello %s" name))
> > > 
> > > I am using following:
> > > 
> > > (defun my-fun-2 (&optional name)
> > >   (interactive)
> > >   (let ((name (or name (read-from-minibuffer "Name: "))))
> > >     (message "Hello %s" name)))
> > > 
> > > as that gives me little more freedom:
> > > 
> > > - if I call (my-fun-1) ⇒ "Hello nil" that result is not what I
> > >  really want. It makes it difficult to get the wanted result. To
> > >  get the wanted result I need to use:
> > > 
> > > (call-interactively 'my-fun-1) ⇒ "Hello Bob"
> > > 
> > > - but if I call (my-fun-2) and NAME is not supplied, I will be
> > >   asked for name: (my-fun-2) ⇒ "Hello Bob" and will not get "NIL"
> > >   as result. In this case I need not complicate the call and use
> > > `call-interactively`.
> > > 
> > > Additionall, complex `interactive` clauses I find often too
> > > difficult to comprehend than reading the body of the function.
> > 
> > Yes, but you are forced for interactive commands.  It is not equivalent
> > to a function that is non-interactive.
> 
> You are not forced to supply arguments within (interactive), not at
> all. Function may not need any arguments. But if it has prefix you
> should declare (interactive "P"). But if it needs some text input you
> may say (interactive "MInput: ")
> 
> However, I have explained in the above example of mine that such input
> may be provided in the function itself. And it looks to me that it is
> better handled that way than through `interactive' declaration.

You can call it within lisp code for sure.  With interactive to set function 
arguments, you are also correct.  In the broader context of considering
any input from minibuffer as user interactive, it could make some problems.  


 
> So this is the way to go:
> 
> (defun my-fun-2 (&optional name)
>   (interactive)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))
> 
> Function `interactive' DOES NOT make function "interactive" in the
> other contexts in English language, there is special meaning in the
> Emacs Lisp context. Programming meaning is simply not same to English
> context.
> 
> To call function interactively, it means not to call it exclusively
> from Lisp, but from the user interface by using M-x or key. 
> 
> That means, when there is declaration (interactive), that function
> becomes accessible through M-x invokation, and it may be bound to a
> key. 
> 
> It means then you can run the function by pressing a key (that is what
> is meant with "interactively") or by invoking the function with M-x
> or through menus.
> 
> IT DOES NOT EXCLUDE that other functions without the declaration
> "(interactive)" are and can be "interactive" in the meaning of English
> language.
> 
> You may thus have a function that is command and that may be invoked
> interactively because of declaration "(interactive)":
> 
> (defun my-fun-2 (&optional name)
>   (interactive)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))
> 
> And you may have interactive function, that interacts with user
> without declaration "(interactive)":
> 
> (defun my-fun-3 (&optional name)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))
> 
> And that function in the meaning of English language is interactive,
> but is not a command in the meaning of Emacs Lisp because it does not
> have declaration "(interactive)".
> 
> 
> ,----
> | Specify a way of parsing arguments for interactive use of a function.
> | For example, write
> |  (defun foo (arg buf) "Doc string" (interactive "P\nbbuffer: ") .... )
> |  to make ARG be the raw prefix argument, and set BUF to an existing buffer,
> |  when ‘foo’ is called as a command.
> | 
> | The "call" to ‘interactive’ is actually a declaration rather than a
> |  function; it tells ‘call-interactively’ how to read arguments to pass
> |  to the function.  When actually called, ‘interactive’ just returns
> |  nil.
> | 
> | Usually the argument of ‘interactive’ is a string containing a code
> |  letter followed optionally by a prompt.  (Some code letters do not
> |  use I/O to get the argument and do not use prompts.)  To pass several
> |  arguments to the command, concatenate the individual strings,
> |  separating them by newline characters.
> | 
> | Prompts are passed to ‘format’, and may use %s escapes to print the
> |  arguments that have already been read.
> | 
> | If the argument is not a string, it is evaluated to get a list of
> |  arguments to pass to the command.
> | 
> | Just ‘(interactive)’ means pass no arguments to the command when
> |  calling interactively.
> `----
> 
> 
> -- 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
>

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 15, 2022, 07:26 by bugs@gnu.support:

> Most of time I do not use `interactive' for supply arguments to
> function.
>
> Thus instead of following:
>
> (defun my-fun-1 (&optional name)
>  (interactive "MName: ")
>  (message "Hello %s" name))
>
> I am using following:
>
> (defun my-fun-2 (&optional name)
>  (interactive)
>  (let ((name (or name (read-from-minibuffer "Name: "))))
>  (message "Hello %s" name)))
>
> as that gives me little more freedom:
>
> - if I call (my-fun-1) ⇒ "Hello nil" that result is not what I
>  really want. It makes it difficult to get the wanted result. To
>  get the wanted result I need to use:
>
> (call-interactively 'my-fun-1) ⇒ "Hello Bob"
>
> - but if I call (my-fun-2) and NAME is not supplied, I will be
>  asked for name: (my-fun-2) ⇒ "Hello Bob" and will not get "NIL"
>  as result. In this case I need not complicate the call and use
> `call-interactively`.
>
> Additionall, complex `interactive` clauses I find often too
> difficult to comprehend than reading the body of the function.
>
> Fo this reason I recommend using this second approach with (or
> ARGUMENT (GET-ARGUMENT)) rather then using `interactive` with
> purpose to supply arguments.
>
> -- 
> Jean
>

If with GET-ARGUMENT you use a command that calls the minibuffer, then calling
the function in lisp code will ask the user for input.  Something that a pure function
call in elisp code does not normally do.

RE: [External] : Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 22:52 by drew.adams@oracle.com:

>> > Maybe going through the "Introduction to Emacs Lisp" (see "Help =>
>> > More Manual => Introduction to Emacs Lisp" in the menu) will be helpful.
>>
>> Can you make clear what sections should I read to answer my question?
>>
>
> <unsolicited-advice>
>
> * Menu:
>
> * Lisp Lists::                  What are lists?
> * Run a Program::               Any list in Lisp is a program ready to run.
> * Making Errors::               Generating an error message.
> * Names & Definitions::         Names of symbols and function definitions.
> * Lisp Interpreter::            What the Lisp interpreter does.
> * Evaluation::                  Running a program.
> * Variables::                   Returning a value from a variable.
> * Arguments::                   Passing information to a function.
> * set & setq::                  Setting the value of a variable.
> * Summary::                     The major points.
> * Error Message Exercises::
>
> </unsolicited-advice>
>
The only thing I captured from re-reading all that was that something like `(let' behaves like a function (special form).  The variable setting sets the value but do not define any output.

But I also found that by default, a function in lisp returns the value of the last expression evaluated as the return value.  Hence, the last expression in the body of the `let' clause is the entity that is returned by `let'.

Re: Placement of list within an interactive clause

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-07-15 13:33]:
> You can call it within lisp code for sure.  With interactive to set function 
> arguments, you are also correct.  In the broader context of considering
> any input from minibuffer as user interactive, it could make some
> problems.  

Do you realise that "read-from-minibuffer" is not function declared
(interactive) and is not a command, it cannot be placed on a key, or
called from M-x, but it asks user to interact with minibuffer.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[Jean Louis]

* carlmarcos@tutanota.com <carlmarcos@tutanota.com> [2022-07-15 22:55]:
> If with GET-ARGUMENT you use a command that calls the minibuffer,
> then calling the function in lisp code will ask the user for input.
> Something that a pure function call in elisp code does not normally
> do.

From Emacs Lisp manual:

A “pure function” is a function which, in addition to having
no side effects, always returns the same value for the same combination
of arguments, regardless of external factors such as machine type or
system state.

I know what you mean.

However (read-from-minibuffer "Input: ") does not have side effects,
and returns same value for same combination of arguments. It is not a
command and cannot be, in the context of Emasc Lisp, called
interactively like with M-x -- and it is interacting with user.

1) There is no reason to have all functions "pure functions" just to
   satisfy who? Theorists? But I need practical use.

2) The definition which I found apply to many functions, it does not
   exclude user input. Does it? For me user input is argument to
   interactive function.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 15, 2022, 21:03 by bugs@gnu.support:

> * Christopher Dimech <dimech@gmx.com> [2022-07-15 13:33]:
>
>> You can call it within lisp code for sure.  With interactive to set function 
>> arguments, you are also correct.  In the broader context of considering
>> any input from minibuffer as user interactive, it could make some
>> problems.
>>
>
> Do you realise that "read-from-minibuffer" is not function declared
> (interactive) and is not a command, it cannot be placed on a key, or
> called from M-x, but it asks user to interact with minibuffer.
>
> -- 
> Jean
>
Yes, I realise that.  I see that (interactive) is misleading.  Although "read-from-minibuffer"
cannot be called from M-x, it still asks for input through the minibuffer.  Notwithstanding   
that normal programming language code does not customarily lead to user input during 
run-time, particularly when automation is pursued.

Re: Placement of list within an interactive clause

[Jean Louis]

* carlmarcos@tutanota.com <carlmarcos@tutanota.com> [2022-07-16 00:23]:
> Yes, I realise that.  I see that (interactive) is misleading. 
> Although "read-from-minibuffer" cannot be called from M-x, it still
> asks for input through the minibuffer.  Notwithstanding   that
> normal programming language code does not customarily lead to user
> input during run-time, particularly when automation is pursued.

Emacs Lisp is what it is. Text editor IS interactive as by the context
of English language. Declaration "(interactive)" is not misleading as
it has pretty good description what it is. If you however, do not
understand any word in that description, let us know.

The misnderstanding comes when you try mixing various context, you
know the context of "interactive" in English and then you assume it is
same contect in Emacs Lisp, while it is not.

While definition for declaration "(interactive)" may be found in
Emacs, this definition below is found in Wordnet dictionary:

* Overview of adj interactive

The adj interactive has 2 senses (no senses from tagged texts)
1. synergistic, interactive -- (used especially of drugs or muscles that work together so the total effect is greater than the sum of the two (or more))
2. interactional, interactive -- (capable of acting on or influencing each other)

And it is obvious that definition number 2 fits into what we are
speaking about, not the number 1, as Emacs functions are not related
to muscles or drugs.

If I think of who or what is "each other", maybe those are functions,
maybe screen, thus majority of functions could be said to be
interactive by English language context.

If function changes color of Emacs editor, it is interactive. If it
influences other function it is interactive. Do we need to consider
"interactive" only if it influences human? It influences 2 parties or
things, it is not clear quite, it is "each other". If function
influences computer time, it is interactive.

Is the definition really that what we are talking about?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[Stefan Monnier via Users list for the GNU Emacs text editor]

> (defun my-fun-2 (&optional name)
>   (interactive)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))

Side note: `read-from-minibuffer` should probably be replaced here with
`read-string`.  `read-from-minibuffer` is intended to be a low-level
function upon which other `read-<foo>` functions are defined (such as
`read-number`, read-string`, ...).


        Stefan

Re: Placement of list within an interactive clause

[Christopher Dimech]

> 2. interactional, interactive -- (capable of acting on or influencing each other)
>
> And it is obvious that definition number 2 fits into what we are
> speaking about.
>
> If I think of who or what is "each other", maybe those are functions,
> maybe screen, thus majority of functions could be said to be
> interactive by English language context.
>
> If function changes color of Emacs editor, it is interactive. If it
> influences other function it is interactive. Do we need to consider
> "interactive" only if it influences human? It influences 2 parties or
> things, it is not clear quite, it is "each other". If function
> influences computer time, it is interactive.


If what is meant in any interaction influencing one thing with another, then everything
is interactive.  The result is that the use of interactive ends up having no value, because
of its inability to discriminate anything.

For this reason, interactive should represent a specific thing, specifically user-interactive.
Because emacs is fundamentally a user defined environment that accepts user input during run-time.
I personally distinguish traditional coding directed towards automation, and functionalities
that interact directly with the user in the form of text.  In this context I do not consider taking
the position of a region as user-interactive because the user is mostly oblivious to those numeric
details.



> Is the definition really that what we are talking about?

> --
> Jean

Re: Placement of list within an interactive clause

[Jean Louis]

* Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-07-16 00:55]:
> > (defun my-fun-2 (&optional name)
> >   (interactive)
> >   (let ((name (or name (read-from-minibuffer "Name: "))))
> >     (message "Hello %s" name)))
> 
> Side note: `read-from-minibuffer` should probably be replaced here with
> `read-string`.  `read-from-minibuffer` is intended to be a low-level
> function upon which other `read-<foo>` functions are defined (such as
> `read-number`, read-string`, ...).

Sounds reasonable. 

I have removed all occurences of `read-from-minibuffer' from my
programs and replaced it with different function.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 15, 2022, 21:31 by bugs@gnu.support:

> * carlmarcos@tutanota.com <carlmarcos@tutanota.com> [2022-07-16 00:23]:
>
>> Yes, I realise that.  I see that (interactive) is misleading. 
>> Although "read-from-minibuffer" cannot be called from M-x, it still
>> asks for input through the minibuffer.  Notwithstanding   that
>> normal programming language code does not customarily lead to user
>> input during run-time, particularly when automation is pursued.
>>
>
> Emacs Lisp is what it is. Text editor IS interactive as by the context
> of English language. Declaration "(interactive)" is not misleading as
> it has pretty good description what it is. If you however, do not
> understand any word in that description, let us know.
>
>
It is misleading when you do not use it, but having the body run minibuffer commands
in the body.  If you want to make a function without ever interacting with the user (with 
either M-x or whatever), then calling any minibuffer functionality in the body is contrary
to what you want to do.  That's all I am saying.

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 14, 2022, 21:12 by monnier@iro.umontreal.ca:

> carlmarcos@tutanota.com [2022-07-14 22:52:43] wrote:
>
>> My question was about how I can determine which parts are used to fill
>> elements to the list.  Whether it is from the body of `if' and `let'
>> clauses.  Perhaps I was not so articulate in the choice of words.
>>
>
> And my answer is that the expression returns a list and the origin of
> each part of the list is determined by the general semantics of Emacs
> Lisp (which is basically the same as that of all other programming
> languages in this respect).
>
>  Stefan
>
I have been reading as instructed.  

In summary. `(let` is a special function form. And a function in lisp returns the value of the last expression evaluated as the  return value.

Consequently, the following function will only take the last expression in the `let' body (completing-read) to fill an element of a list for setting the function argument `type'.

(defun myfun (type)
(interactive
(list
  (let ( (rqmatch t) (initpk "mixed") (dflt "extended")
(cseq '("expression" "mixed")) )
    (message "This is a message")
    (completing-read "Flare_type: " cseq nil rqmatch initpk nil dflt)))))

On the other hand if I want to have multiple function arguments, I should have

(defun myfun (type other-arg)
  (interactive
   (let ( (rqmatch t) (initpk "mixed") (dflt "extended")
  (cseq '("expression" "mixed")) )
     (message "This is a message")

     (list
      (completing-read "Flare_type: " cseq nil
       rqmatch initpk nil dflt)
      (completing-read "Other_arg: " cseq nil
       rqmatch initpk nil dflt)))))

Re: Placement of list within an interactive clause

[Jean Louis]

* carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-07-17 01:09]:
> 
> Jul 15, 2022, 21:31 by bugs@gnu.support:
> 
> > * carlmarcos@tutanota.com <carlmarcos@tutanota.com> [2022-07-16 00:23]:
> >
> >> Yes, I realise that.  I see that (interactive) is misleading. 
> >> Although "read-from-minibuffer" cannot be called from M-x, it still
> >> asks for input through the minibuffer.  Notwithstanding   that
> >> normal programming language code does not customarily lead to user
> >> input during run-time, particularly when automation is pursued.
> >>
> >
> > Emacs Lisp is what it is. Text editor IS interactive as by the context
> > of English language. Declaration "(interactive)" is not misleading as
> > it has pretty good description what it is. If you however, do not
> > understand any word in that description, let us know.
> >
> >
> It is misleading when you do not use it, but having the body run
> minibuffer commands in the body.  If you want to make a function
> without ever interacting with the user (with either M-x or
> whatever), then calling any minibuffer functionality in the body is
> contrary to what you want to do.  That's all I am saying.

Emacs is very interactive. 

Do you maybe think that functions without (interactive) declaration
shall not ask user anything? 

When invoked only from Lisp there are many uses for such functions. 

Does it really need to be text input to be considered interactive?

Logging of activities may be displayed in a buffer, that is
interactive too. Input alone is not interaction. Changing Emacs style
is also interaction and need not be invoked interactively.

What about this? I am just looking into some files and I find many of
functions do have strong interactivity, and they are on my side called
form Lisp. I need not call them from M-x or have them as a command
just because functions is interacting with user.

(defun my-alarm ()
  (start-process "Alarm" "Alarm" "mpv" "/home/data1/protected/Media/Videos/Rooster Crowing Compilation Plus - Rooster crowing sounds Effect 2016.mp4"))


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: Placement of list within an interactive clause

[Drew Adams]

There's been a lot of "noise" and running
around the barn (and around and around again)
in this thread regarding what "interactivity"
and "interactive" mean, could mean, or should
mean, for Emacs.

In Emacs jargon, an "interactive function" is
another name for a "command".  That's all.
And that's all that the `interactive' spec is
for: to make a function interactive.

What does that mean - what is an interactive
function?  It's just a function that you can
invoke in either of these ways:

 * Using `M-x' followed by the function name
 * Using a key that is bound to the function.

That's _all_ it means, in Emacs jargon.  In
particular, it has _NOTHING_ whatsoever, per
se, to do with any reading of user input,
from the minibuffer or in any other way.

Certainly, a function that reads user input
can be said to be interacting with the user.
But an `interactive' spec is not about that.

HTH.

Re: Placement of list within an interactive clause

[Christopher Dimech]

> Sent: Sunday, July 17, 2022 at 11:40 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: carlmarcos@tutanota.com
> Cc: "Christopher Dimech" <dimech@gmx.com>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Placement of list within an interactive clause
>
> * carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-07-17 01:09]:
> > 
> > Jul 15, 2022, 21:31 by bugs@gnu.support:
> > 
> > > * carlmarcos@tutanota.com <carlmarcos@tutanota.com> [2022-07-16 00:23]:
> > >
> > >> Yes, I realise that.  I see that (interactive) is misleading. 
> > >> Although "read-from-minibuffer" cannot be called from M-x, it still
> > >> asks for input through the minibuffer.  Notwithstanding   that
> > >> normal programming language code does not customarily lead to user
> > >> input during run-time, particularly when automation is pursued.
> > >>
> > >
> > > Emacs Lisp is what it is. Text editor IS interactive as by the context
> > > of English language. Declaration "(interactive)" is not misleading as
> > > it has pretty good description what it is. If you however, do not
> > > understand any word in that description, let us know.
> > >
> > >
> > It is misleading when you do not use it, but having the body run
> > minibuffer commands in the body.  If you want to make a function
> > without ever interacting with the user (with either M-x or
> > whatever), then calling any minibuffer functionality in the body is
> > contrary to what you want to do.  That's all I am saying.
> 
> Emacs is very interactive. 
> 
> Do you maybe think that functions without (interactive) declaration
> shall not ask user anything? 
> 
> When invoked only from Lisp there are many uses for such functions. 

Sure, but if you want a fully non-interactive function, do not call 
minibuffer functionality in the body of the function.
 
> Does it really need to be text input to be considered interactive?
> 
> Logging of activities may be displayed in a buffer, that is
> interactive too. Input alone is not interaction. Changing Emacs style
> is also interaction and need not be invoked interactively.

Defining interaction too broadly makes it useless, because it cannot 
distinguish between anything.  For emacs, interaction should always
be associated with direct user input (never with automatic input or
customisation within the program through elisp, unless you ask the user
to directly input operational inputs).

For the broader context one can describe "intercommunication" with emacs.
Interactive in emacs in most times associated with user interaction via
M-x or keybinding.


 
> What about this? I am just looking into some files and I find many of
> functions do have strong interactivity, and they are on my side called
> form Lisp. I need not call them from M-x or have them as a command
> just because functions is interacting with user.

I would also call them interactive functions, even though you do not call them 
with M-x. 
 
> (defun my-alarm ()
>   (start-process "Alarm" "Alarm" "mpv" "/home/data1/protected/Media/Videos/Rooster Crowing Compilation Plus - Rooster crowing sounds Effect 2016.mp4"))
> 
> 
> -- 
> Jean
> 
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
> 
> In support of Richard M. Stallman
> https://stallmansupport.org/
> 
>

Re: RE: [External] : Placement of list within an interactive clause

[Christopher Dimech]

> Sent: Sunday, July 17, 2022 at 1:22 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Jean Louis" <bugs@gnu.support>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: RE: [External] : Re: Placement of list within an interactive clause
>
> There's been a lot of "noise" and running
> around the barn (and around and around again)
> in this thread regarding what "interactivity"
> and "interactive" mean, could mean, or should
> mean, for Emacs.
>
> In Emacs jargon, an "interactive function" is
> another name for a "command".  That's all.
> And that's all that the `interactive' spec is
> for: to make a function interactive.
>
> What does that mean - what is an interactive
> function?  It's just a function that you can
> invoke in either of these ways:
>
>  * Using `M-x' followed by the function name
>  * Using a key that is bound to the function.

Correct.  And always associated with user action.  An is
the notion of command.  It is not just an arbitrary command
though, but commands that a user can access whilst running
the program.

> That's _all_ it means, in Emacs jargon.  In
> particular, it has _NOTHING_ whatsoever, per
> se, to do with any reading of user input,
> from the minibuffer or in any other way.

Sure.  Still, calling minibuffer commands without making
the function a user-accessible command (via M-x), is still
user-interactive in nature.

> Certainly, a function that reads user input
> can be said to be interacting with the user.
> But an `interactive' spec is not about that.

It is actually, it is so user can access with M-x.
Has nothing to do with functionality that emacs simply
does under the hood.  Most of what is done under the
hood is not important to the user.  What is important
to the user is the commands he can launch.  For him,
that is what he defined interaction.  Non-interactive
is when he cannot interact with emacs commands (either
with M-x or minibuffer reads).

> HTH.
>

Re: Placement of list within an interactive clause

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-07-17 04:53]:

> > Emacs is very interactive. 
> > 
> > Do you maybe think that functions without (interactive) declaration
> > shall not ask user anything? 
> > 
> > When invoked only from Lisp there are many uses for such functions. 
> 
> Sure, but if you want a fully non-interactive function, do not call 
> minibuffer functionality in the body of the function.

OK and now, how do I apply that advise? If I want X, then do not do
Y. Of course. But how is such advise practically useful?

What you are saying, seem to come from programming theories.

> > Does it really need to be text input to be considered interactive?
> > 
> > Logging of activities may be displayed in a buffer, that is
> > interactive too. Input alone is not interaction. Changing Emacs style
> > is also interaction and need not be invoked interactively.
> 
> Defining interaction too broadly makes it useless, because it cannot 
> distinguish between anything.  For emacs, interaction should always
> be associated with direct user input (never with automatic input or
> customisation within the program through elisp, unless you ask the user
> to directly input operational inputs).

If you decide to manipulate paragraph it is direct user input. If you
press button to open browser it is direct user input. All key presses
represent direct user input.

Including sound recording, it is also direct user input.

What would be example of indirect user input? Let me know about it.

> For the broader context one can describe "intercommunication" with emacs.
> Interactive in emacs in most times associated with user interaction via
> M-x or keybinding.

Word may have different definitions. Which definition applies depends
of the context of the word. You are mixing both Emacs definition of
(interactive) and common definitions. And then you insist that a beep,
flash, movement of window borders, text scaling, paragraph
manipulations and similar are not interactive, but only minibuffer
input is to be considered interactive. And now we have a new word
"intercommunication" as well. Too much theory, too little practical
use. In general, theory does not bring nothing without practical use.

What is (interactive) is not same as "interactive" as in English
language.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Placement of list within an interactive clause

[Stefan Monnier]

> On the other hand if I want to have multiple function arguments, I should have
>
> (defun myfun (type other-arg)
>   (interactive
>    (let ( (rqmatch t) (initpk "mixed") (dflt "extended")
>   (cseq '("expression" "mixed")) )
>      (message "This is a message")
>
>      (list
>       (completing-read "Flare_type: " cseq nil
>        rqmatch initpk nil dflt)
>       (completing-read "Other_arg: " cseq nil
>        rqmatch initpk nil dflt)))))

For example, yes.

There are many other ways to write such code and the shape if the code
has no importance to `interactive`.  All that matters for `interactive`
is the *value* that is returned when the code is done running.

So you can use your above code (re-indented here, and removed the
initial value which is not helpful here (rarely is)):

    (defun myfun (type other-arg)
      (interactive
       (let ((rqmatch t) (dflt "extended") (cseq '("expression" "mixed")))
         (message "This is a message")
         (list
          (completing-read "Flare_type: " cseq nil rqmatch nil nil dflt)
          (completing-read "Other_arg: " cseq nil rqmatch nil nil dflt))))
      ...)

or

    (defun myfun (type other-arg)
      (interactive
       (list
        (let ((rqmatch t) (dflt "extended") (cseq '("expression" "mixed")) )
          (message "This is a message")
          (completing-read "Flare_type: " cseq nil rqmatch nil nil dflt))
        (let ((rqmatch t) (dflt "extended") (cseq '("expression" "mixed")) )
          (message "This is another message")
          (completing-read "Flare_type: " cseq nil rqmatch nil nil dflt))))
      ...)

or

    (defun myfun (type other-arg)
      (interactive
       (let ((rqmatch t) (dflt "extended") (cseq '("expression" "mixed")))
         (message "This is a message")
         (let ((x (completing-read "Flare_type: " cseq nil rqmatch nil nil dflt))
               (y (completing-read "Other_arg: " cseq nil rqmatch nil nil dflt)))
          `(,x ,y))))
      ...)

or

    (defun myfun (type other-arg)
      (interactive
       (let ((rqmatch t) (dflt "extended") (cseq '("expression" "mixed")))
         (message "This is a message")
         (mapcar (lambda (prompt)
                   (completing-read prompt cseq nil rqmatch nil nil dflt))
                 '("Flare_type: " "Other_arg: "))))
      ...)

or

    ...


-- Stefan

Re: Placement of list within an interactive clause

[Christopher Dimech]

> Sent: Sunday, July 17, 2022 at 2:16 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: carlmarcos@tutanota.com, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Placement of list within an interactive clause
>
> * Christopher Dimech <dimech@gmx.com> [2022-07-17 04:53]:
>
> > > Emacs is very interactive.
> > >
> > > Do you maybe think that functions without (interactive) declaration
> > > shall not ask user anything?
> > >
> > > When invoked only from Lisp there are many uses for such functions.
> >
> > Sure, but if you want a fully non-interactive function, do not call
> > minibuffer functionality in the body of the function.
>
> OK and now, how do I apply that advise? If I want X, then do not do
> Y. Of course. But how is such advise practically useful?
>
> What you are saying, seem to come from programming theories.

Yes, because users need a sensible way  to navigate the code.  When experienced
programmers stumble, focused terminology would make things quite clear.
Terminology that is too broad has no practical value.

> > > Does it really need to be text input to be considered interactive?
> > >
> > > Logging of activities may be displayed in a buffer, that is
> > > interactive too. Input alone is not interaction. Changing Emacs style
> > > is also interaction and need not be invoked interactively.
> >
> > Defining interaction too broadly makes it useless, because it cannot
> > distinguish between anything.  For emacs, interaction should always
> > be associated with direct user input (never with automatic input or
> > customisation within the program through elisp, unless you ask the user
> > to directly input operational inputs).
>
> If you decide to manipulate paragraph it is direct user input. If you
> press button to open browser it is direct user input. All key presses
> represent direct user input.

Yes, but is automatic.  There is no user prose involved.

> Including sound recording, it is also direct user input.
>
> What would be example of indirect user input? Let me know about it.
>
> > For the broader context one can describe "intercommunication" with emacs.
> > Interactive in emacs in most times associated with user interaction via
> > M-x or keybinding.
>
> Word may have different definitions. Which definition applies depends
> of the context of the word. You are mixing both Emacs definition of
> (interactive) and common definitions. And then you insist that a beep,
> flash, movement of window borders, text scaling, paragraph
> manipulations and similar are not interactive, but only minibuffer
> input is to be considered interactive. And now we have a new word
> "intercommunication" as well. Too much theory, too little practical
> use. In general, theory does not bring nothing without practical use.

You misunderstood.  Only mentioned that using minibuffer input without
declaring the enclosing function a command, does not make the function
non-interactive to the user.

It is theory that people would know as part of their formal education.
Experience in other languages and areas should help one go through the
emacs code on their own.  We are not there yet.

> What is (interactive) is not same as "interactive" as in English
> language.
>
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

Re: Placement of list within an interactive clause

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jul 17, 2022, 02:38 by monnier@iro.umontreal.ca:

>> On the other hand if I want to have multiple function arguments, I should have
>>
>> (defun myfun (type other-arg)
>>   (interactive
>>    (let ( (rqmatch t) (initpk "mixed") (dflt "extended")
>>   (cseq '("expression" "mixed")) )
>>      (message "This is a message")
>>
>>      (list
>>       (completing-read "Flare_type: " cseq nil
>>        rqmatch initpk nil dflt)
>>       (completing-read "Other_arg: " cseq nil
>>        rqmatch initpk nil dflt)))))
>>
>
> For example, yes.
>
> There are many other ways to write such code and the shape if the code
> has no importance to `interactive`.  All that matters for `interactive`
> is the *value* that is returned when the code is done running.
>
Thank you so very much for the examples.  I am now fully conversant
on the details of working with interactive.

Re: Placement of list within an interactive clause

[Stefan Monnier]

carlmarcos@tutanota.com [2022-07-17 05:02:48] wrote:
> Thank you so very much for the examples.  I am now fully conversant
> on the details of working with interactive.

Hmm... my point was that none of these are details related to `interactive`.


        Stefan

Re: Placement of list within an interactive clause

[Emanuel Berg]

Jean Louis wrote:

> However, I have explained in the above example of mine that
> such input may be provided in the function itself. And it
> looks to me that it is better handled that way than through
> `interactive' declaration.

Cases that can't be handled by the ARG-DESCRIPTOR argument can
be handled with Lisp, if so the best place for that is within
the `interactive' form ...

> So this is the way to go:
>
> (defun my-fun-2 (&optional name)
>   (interactive)
>   (let ((name (or name (read-from-minibuffer "Name: "))))
>     (message "Hello %s" name)))

Here it is better to make the argument non-optional,
i.e. mandatory from Lisp, and interactively like this

  (interactive "sName: ")

> That means, when there is declaration (interactive), that
> function becomes accessible through M-x invokation, and it
> may be bound to a key.

Yes, it becomes a "command".

I don't know if I like this solution TBH, I think all
functions should be callable from everywhere and make sense
everywhere, called in whatever way they might ...

Dutch total football, if you like ...

> Function `interactive' DOES NOT make function "interactive"
> in the other contexts in English language, there is special
> meaning in the Emacs Lisp context. Programming meaning is
> simply not same to English context.

Programming should always be in English but it isn't
English LOL :D

-- 
underground experts united
https://dataswamp.org/~incal