Exiting from mapc

Exiting from mapc

[Heime via Users list for the GNU Emacs text editor]

How can I exit when encountering 'safg or 'nogo 

(defun amazones-falkotr-kntlr (actm-seqr)

  (mapc

    (lambda (actm)
      ;; Evaluate conditions and executes corresponding actions
      ;; based on matching clauses.

      (cond

        ;; CASE
        ((eq actm 'safg)
           (message "SAFG amazones-falkotr-kntlr"))

	;; CASE
        ((eq actm 'armg)
	   (message "ARMG amazones-falkotr-kntlr")
           ;; Load falkotr.el from `load-path'.
           (add-to-list 'load-path (amazones-fpln-waypt "FLKTR" 'sec))
           (require 'falkotr))

	 ;; CASE
         ((eq actm 'nogo)
            (message "NOGO amazones-falkotr-kntlr"))

        ;; CASE
         ((eq actm 'go)
            (message "GO amazones-falkotr-kntlr")
            (falkotr-launch-kntlr '(armg go)))

         ;; CASE
         (t
            ;; Unrecognised symbol, log error with offending symbol.
            (message "NOGO amazones-falkotr-kntlr")
            (message " └── ACTM Unrecognised: %s" actm))))

   actm-seqr))






Sent with Proton Mail secure email.

RE: [External] : Exiting from mapc

[Drew Adams]

> How can I exit when encountering 'safg or 'nogo

As usual, wrap with a `catch', and `throw' to it whenever you like.

RE: [External] : Exiting from mapc

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Wednesday, January 1st, 2025 at 8:13 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > How can I exit when encountering 'safg or 'nogo
> 
> 
> As usual, wrap with a `catch', and` throw' to it whenever you like.

Does the catch statement belong before mapc? 

RE: [External] : Exiting from mapc

[Drew Adams]

> > > How can I exit when encountering 'safg or 'nogo
> >
> > As usual, wrap with a `catch', and` throw' to it whenever you like.
> 
> Does the catch statement belong before mapc?

Yes - "wrap".


(defun amazones-falkotr-kntlr (actm-seqr)
  (catch 'RTFM
    (mapc (lambda (...)
            <Do whatever, and `throw' any value,
             from anywhere here, to 'RTFM>)
          actm-seqr))))

1. `C-h f catch'

2. https://www.gnu.org/software/emacs/manual/html_node/elisp/Catch-and-Throw.html

Learning to use `catch' and `throw' with code
such as iteration is basic.  And catch/throw is
a building block for implementing other iteration
etc. constructs.

The Elisp code that Emacs provides so freely to
you is a great place to learn about Elisp.  Grep
for `catch' there...

Here's a simple example:

(defmacro while-no-input (&rest body)
  "..."
  (declare (debug t) (indent 0))
  (let ((catch-sym (make-symbol "input")))
    `(with-local-quit
       (catch ',catch-sym
	 (let ((throw-on-input ',catch-sym))
	   (or (input-pending-p)
	       (progn ,@body)))))))

Here's another:

(defun get-window-with-predicate (predicate &optional minibuf all-frames default)
  "..."
  (catch 'found
    (dolist (window (window-list-1
		     (next-window nil minibuf all-frames)
		     minibuf all-frames))
      (when (funcall predicate window)
	(throw 'found window)))
    default))

The Elisp manual makes great bedtime reading.
Time better spent than asking help-gnu-emacs,
perhaps.

RE: [External] : Exiting from mapc

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Wednesday, January 1st, 2025 at 10:30 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > > > How can I exit when encountering 'safg or 'nogo
> > > 
> > > As usual, wrap with a `catch', and` throw' to it whenever you like.
> > 
> > Does the catch statement belong before mapc?
> 
> 
> Yes - "wrap".
> 
> 
> (defun amazones-falkotr-kntlr (actm-seqr)
> (catch 'RTFM
> (mapc (lambda (...)
> <Do whatever, and `throw' any value,
> from anywhere here, to 'RTFM>)
> 
> actm-seqr))))
> 
> 1. `C-h f catch' 2. https://www.gnu.org/software/emacs/manual/html_node/elisp/Catch-and-Throw.html Learning to use` catch' and `throw' with code such as iteration is basic. And catch/throw is a building block for implementing other iteration etc. constructs. The Elisp code that Emacs provides so freely to you is a great place to learn about Elisp. Grep for` catch' there...
> 
> Here's a simple example:
> 
> (defmacro while-no-input (&rest body)
> "..."
> (declare (debug t) (indent 0))
> (let ((catch-sym (make-symbol "input")))
> `(with-local-quit
> (catch ',catch-sym
> (let ((throw-on-input ',catch-sym))
> (or (input-pending-p)
> (progn ,@body)))))))
> 
> Here's another:
> 
> (defun get-window-with-predicate (predicate &optional minibuf all-frames default)
> "..."
> (catch 'found
> (dolist (window (window-list-1
> (next-window nil minibuf all-frames)
> minibuf all-frames))
> (when (funcall predicate window)
> (throw 'found window)))
> default))

How can one get  the result of the throw?  With a let?
 
> The Elisp manual makes great bedtime reading.
> Time better spent than asking help-gnu-emacs,
> perhaps.

Re: [External] : Exiting from mapc

[Joel Reicher]

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

> How can one get  the result of the throw?  With a let?

Why are you asking on this list when it should be possible to get 
this information from (info "(elisp) Catch and Throw")?

Regards,

        - Joel

Re: [External] : Exiting from mapc

[Jean Louis]

* Joel Reicher <joel.reicher@gmail.com> [2025-01-02 03:33]:
> Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> writes:
> 
> > How can one get  the result of the throw?  With a let?
> 
> Why are you asking on this list when it should be possible to get this
> information from (info "(elisp) Catch and Throw")?

Sometimes it is helpful to provide info, and too often people have
misunderstanding and need explanation. Emacs is full of terms,
concepts, definitions which cause misunderstandings. If that would not
be so, I would be very happy, though it is.

You must know that there are different types of readers, different
audience. Emacs Lisp manual is written in technical manner, it wasn't
written in manner of a tutorial.

Imagine people in need of tutorial reading just this sentence:

11.7.1 Explicit Nonlocal Exits: ‘catch’ and ‘throw’

Even if not a beginner, experienced programmer could mix those terms
with something else.

Unspoken of the rest of the article:

"Most control constructs affect only the flow of control within the
construct itself. " -- what level of programming person must already
have to undersand only this first sentence? Reader must already have
basic programming knowledge, control structure understanding, scope
awareness, etc. 

If person is not on the level to easily understand just the first
sentence, mind gets blocked, misunderstood words create blanks in the
mind, and people stop using it, and it is good thing that Heime or
other people do not give up, but ask for answers here.

-- 
Jean Louis

Re: [External] : Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

> * Joel Reicher <joel.reicher@gmail.com> [2025-01-02 03:33]:
>> Heime via Users list for the GNU Emacs text editor 
>> <help-gnu-emacs@gnu.org> writes:
>>
>>> How can one get  the result of the throw?  With a let?
>>
>> Why are you asking on this list when it should be possible to 
>> get this information from (info "(elisp) Catch and Throw")?
>
> Sometimes it is helpful to provide info, and too often people 
> have misunderstanding and need explanation. Emacs is full of 
> terms, concepts, definitions which cause misunderstandings. If 
> that would not be so, I would be very happy, though it is.
>
> You must know that there are different types of readers, 
> different audience. Emacs Lisp manual is written in technical 
> manner, it wasn't written in manner of a tutorial.

If the problem is in understanding the manual, then my very strong 
opinion is that the question should be asked in terms of the 
manual.

This does three things:

1) Demonstrates good faith on the part of the enquirer that they 
have attempted to read the manual
2) Helps phrase the question in common terms with a minimum of 
unstated assumptions
3) Potentially leads to improvements in the manual

Regards,

        - Joel

Re: [External] : Exiting from mapc

[Jean Louis]

* Joel Reicher <joel.reicher@gmail.com> [2025-01-03 03:25]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Joel Reicher <joel.reicher@gmail.com> [2025-01-02 03:33]:
> > > Heime via Users list for the GNU Emacs text editor
> > > <help-gnu-emacs@gnu.org> writes:
> > > 
> > > > How can one get  the result of the throw?  With a let?
> > > 
> > > Why are you asking on this list when it should be possible to get
> > > this information from (info "(elisp) Catch and Throw")?
> > 
> > Sometimes it is helpful to provide info, and too often people have
> > misunderstanding and need explanation. Emacs is full of terms, concepts,
> > definitions which cause misunderstandings. If that would not be so, I
> > would be very happy, though it is.
> > 
> > You must know that there are different types of readers, different
> > audience. Emacs Lisp manual is written in technical manner, it wasn't
> > written in manner of a tutorial.
> 
> If the problem is in understanding the manual, then my very strong opinion
> is that the question should be asked in terms of the manual.
> 
> This does three things:
> 
> 1) Demonstrates good faith on the part of the enquirer that they have
> attempted to read the manual
> 2) Helps phrase the question in common terms with a minimum of unstated
> assumptions
> 3) Potentially leads to improvements in the manual

It is very good opinion, but people are not programmed robots.

-- 
Jean Louis

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Van Ly via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

> It is very good opinion, but people are not programmed robots.

People vary in their cognitive styles.

-- 
vl

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Jean Louis]

* Van Ly via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists <emacs-tangents@gnu.org> [2025-01-03 17:32]:
> 
> > It is very good opinion, but people are not programmed robots.
> 
> People vary in their cognitive styles.

Well expressed. 

Jean Louis

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

> * Van Ly via Emacs news and miscellaneous discussions outside 
> the scope of other Emacs mailing lists <emacs-tangents@gnu.org> 
> [2025-01-03 17:32]:
>>
>>> It is very good opinion, but people are not programmed robots.
>>
>> People vary in their cognitive styles.
>
> Well expressed.

It is a truism, and irrelevant in this context.

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Van Ly via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Joel Reicher <joel.reicher@gmail.com> writes:

>>> People vary in their cognitive styles.
>>
>> Well expressed.
>
> It is a truism, and irrelevant in this context.

Feed the manual to the Generative AI and let the user's customized
Interpretative AI Lens one shot the goal state path the user's current
state wishes to obtain.

-- 
vl

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Eduardo Ochs]

On Sat, 11 Jan 2025 at 05:19, Joel Reicher <joel.reicher@gmail.com> wrote:
>
> >> People vary in their cognitive styles.
> >
> > Well expressed.
>
> It is a truism, and irrelevant in this context.


Hi Joel, Jean, Van Ly, and others...

What about this?

Consider these two styles of presenting structures:

  1) (info "(cl)Structures")

  2) (cl-defstruct myabc a b c)
     (setq o (make-myabc :a 22 :c "44"))
     (cl-prin1-to-string o)

The style (1) uses a lot of text and uses structures like this one,

  (cl-defstruct person first-name age sex)

and the style (2) uses very little text and uses "abstract" names like
a, b, and c...

I've seen people who can't understand `a's, `b's, and `c's without
"examples from the real world" and people who are overwhelmed by the
extra connotation of terms "person", "first-name", "age", and "sex",
and who vastly prefer the style (2)...

  Cheers,
    Eduardo Ochs
    http://anggtwu.net/#eev

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Joel Reicher]

Van Ly via Emacs news and miscellaneous discussions outside the 
scope of other Emacs mailing lists <emacs-tangents@gnu.org> 
writes:

>> It is very good opinion, but people are not programmed robots.
>
> People vary in their cognitive styles.

And a person may find on reading the manual that it does not serve 
their style, but because they discover that by reading the manual, 
they can ask their question in terms of what they have just read.

Regards,

        - Joel

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [External] : Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

> * Joel Reicher <joel.reicher@gmail.com> [2025-01-03 03:25]:

[...]

>> If the problem is in understanding the manual, then my very 
>> strong opinion is that the question should be asked in terms of 
>> the manual.
>>
>> This does three things:
>>
>> 1) Demonstrates good faith on the part of the enquirer that 
>> they have attempted to read the manual
>> 2) Helps phrase the question in common terms with a minimum of 
>> unstated assumptions
>> 3) Potentially leads to improvements in the manual
>
> It is very good opinion, but people are not programmed robots.

The manual is not written for robots.

    - Joel

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

was - Exiting from mapc

[Jean Louis]

* Joel Reicher <joel.reicher@gmail.com> [2025-01-11 11:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Joel Reicher <joel.reicher@gmail.com> [2025-01-03 03:25]:
> 
> [...]
> 
> > > If the problem is in understanding the manual, then my very strong
> > > opinion is that the question should be asked in terms of the manual.
> > > 
> > > This does three things:
> > > 
> > > 1) Demonstrates good faith on the part of the enquirer that they
> > > have attempted to read the manual
> > > 2) Helps phrase the question in common terms with a minimum of
> > > unstated assumptions
> > > 3) Potentially leads to improvements in the manual
> > 
> > It is very good opinion, but people are not programmed robots.
> 
> The manual is not written for robots.

The Emacs Lisp manual is meant for everyone, but if it could solve all
the issues people have with Emacs, then there wouldn't be a need for
the help email list where people ask for assistance.

The Emacs Lisp manual is written for everyone, but its writing style
is more suitable for advanced programmers.

The Emacs Lisp Intro manual, on the other hand, is intended for
beginners. However, it does not cover every topic in detail.

Teaching as an art means breaking down complex knowledge into smaller,
easier-to-understand parts. This makes it simpler for the student to
learn and grasp the concepts.

Regardless of what you or I believe, there's usually a lot of
information available, either in manuals or online, where most
questions have already been answered. If I tell someone asking a
question that the answer is already available, it might make them feel
like I'm ignoring their question, which isn't the intention. I'm on
the mailing list to help and engage with people, not to make them feel
dismissed.

If members of mailing list dismiss, ignore or act rudely towards
people who have questions about Emacs, they might go find help in
other communities where they'll receive better treatment.

-- 
Jean Louis

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

[...]

> The Emacs Lisp manual is meant for everyone, but if it could 
> solve all the issues people have with Emacs, then there wouldn't 
> be a need for the help email list where people ask for 
> assistance.
>
> The Emacs Lisp manual is written for everyone, but its writing 
> style is more suitable for advanced programmers.
>
> The Emacs Lisp Intro manual, on the other hand, is intended for 
> beginners. However, it does not cover every topic in detail.
>
> Teaching as an art means breaking down complex knowledge into 
> smaller, easier-to-understand parts. This makes it simpler for 
> the student to learn and grasp the concepts.
>
> Regardless of what you or I believe, there's usually a lot of 
> information available, either in manuals or online, where most 
> questions have already been answered. If I tell someone asking a 
> question that the answer is already available, it might make 
> them feel like I'm ignoring their question, which isn't the 
> intention. I'm on the mailing list to help and engage with 
> people, not to make them feel dismissed.

I anticipated you would say something like this, and I would 
request you be less sure of yourself.

There is a very large difference between saying the answer is 
already available, and pointing out where the answer is to be 
found.

Engagement is a two way street: the contributors to the manual 
have attempted to reduce the need for repetition on the mailing 
list and other forums, and this deserves respect.

Regards,

        - Joel

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Jean Louis]

* Joel Reicher <joel.reicher@gmail.com> [2025-01-11 16:43]:
> Jean Louis <bugs@gnu.support> writes:
> 
> [...]
> 
> > The Emacs Lisp manual is meant for everyone, but if it could solve all
> > the issues people have with Emacs, then there wouldn't be a need for the
> > help email list where people ask for assistance.
> > 
> > The Emacs Lisp manual is written for everyone, but its writing style is
> > more suitable for advanced programmers.
> > 
> > The Emacs Lisp Intro manual, on the other hand, is intended for
> > beginners. However, it does not cover every topic in detail.
> > 
> > Teaching as an art means breaking down complex knowledge into smaller,
> > easier-to-understand parts. This makes it simpler for the student to
> > learn and grasp the concepts.
> > 
> > Regardless of what you or I believe, there's usually a lot of
> > information available, either in manuals or online, where most questions
> > have already been answered. If I tell someone asking a question that the
> > answer is already available, it might make them feel like I'm ignoring
> > their question, which isn't the intention. I'm on the mailing list to
> > help and engage with people, not to make them feel dismissed.
> 
> I anticipated you would say something like this, and I would request you be
> less sure of yourself.
> 
> There is a very large difference between saying the answer is already
> available, and pointing out where the answer is to be found.
> 
> Engagement is a two way street: the contributors to the manual have
> attempted to reduce the need for repetition on the mailing list and other
> forums, and this deserves respect.
> 
> Regards,
> 
>        - Joel

I am an Emacs user, and I have no doubts about my appreciation for
manual authors. That is quite different subject.

I have got the point you are trying to convey: 

- "Read the manual—or else I’ll manually read it to you!" -- irony.

Though learning is not that easy.

Knowledge has to be broken down in parts easy to understand.  

You have problems understanding my viewpoint; for some reason, you
dismiss the notion that people may have different levels of learning.

In a similar way to that event where you couldn't understand my point,
users often have problems understanding whatever we write, whether in
manuals, emails, or verbally, regardless of the method. I hope you get
it.

It requires the teaching party to understand the level of
understanding of the student, and then to break it down in an
accessible way that the student may grasp it.

If it were that easy that each student could learn and understand only
through books, we would not need any teachers or professors to talk or
interact with people; we would only need plain books and pointers to
them.

-- 
Jean Louis

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

[...]

> You have problems understanding my viewpoint; for some reason, 
> you dismiss the notion that people may have different levels of 
> learning.

I do not. I've already asked you to be less sure of yourself.

> In a similar way to that event where you couldn't understand my 
> point, users often have problems understanding whatever we 
> write, whether in manuals, emails, or verbally, regardless of 
> the method. I hope you get it.

It was obvious to me before you said it.

> It requires the teaching party to understand the level of 
> understanding of the student, and then to break it down in an 
> accessible way that the student may grasp it.

That is feedback for the authors of the manual.

> If it were that easy that each student could learn and 
> understand only through books, we would not need any teachers or 
> professors to talk or interact with people; we would only need 
> plain books and pointers to them.

I understand your point, and I've never said the understanding 
should only be through books. I only said the attempt should begin 
with the books in order to respect and assist the attempts of the 
authors.

Regards,

        - Joel

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Jean Louis]

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

* Joel Reicher <joel.reicher@gmail.com> [2025-01-11 17:16]:
> I understand your point, and I've never said the understanding should only
> be through books. I only said the attempt should begin with the books in
> order to respect and assist the attempts of the authors.

I fully agree on that in general.

Though I remember times from 1999 when I was dismissing various Emacs
versions and switching from one to another, mostly to find out why it
was crashing. During that time, there was a lot of information for me,
and I simply couldn't grasp it. There was a bunch of new terminology
and many misunderstood words. From the viewpoint of my personal
experience, I still struggle to understand many details in the manual
today, even after 25 years. I have to study new terms and clarify
them, which is why I have endorsed the integration of a dictionary in
Emacs. On my side, I have some statistics on how many words I have
defined and clarified through Emacs over the last few years. See it
attached.

Here’s a corrected version of your text:

How many times have I not found those terms in the manual? I skipped
too many various resources, and now there are Stack Overflow and Large
Language Model (LLM) knowledge bases, online books about Emacs, and a
plethora of information.

Then I am now in an environment where people do not even read
books. They have smartphones and access to knowledge, but do not read
anything of quality on the Internet and do not read physical paper
books. Everything must be explained verbally. Students in schools in
East Africa verbally discuss issues, but when you ask if they have any
books at home, well, maybe a Bible or Quran, which they have never
read.

Can you imagine that difference?

As you know, mailing lists need not be answered; many questions may
remain unanswered. I do not consider it "traffic," as we currently do
not have much traffic; in fact, we have less people now than before. 

Basically, we need more people asking questions on that mailing
list. 

We need socialization, not automatization. 

Soon, websites may not be searched for knowledge, as each phone will
already have Wikipedia, Britannica, and other resources built in
through tensors from Large Language Models (LLMs).

That will drive many people away from socialization.

We need them.

-- 
Jean Louis

[-- Attachment #2: Screenshot-2025-01-11-17-28-56-373498401.png --]
[-- Type: image/png, Size: 31642 bytes --]

[-- Attachment #3: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Joel Reicher]

Jean Louis <bugs@gnu.support> writes:

> * Joel Reicher <joel.reicher@gmail.com> [2025-01-11 17:16]:

[...]

> Here’s a corrected version of your text:

I'm not sure that what I said needed correcting, and even if it did, the corrections would need to be faithful to my original intent.

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: was - Exiting from mapc

[Jean Louis]

On January 12, 2025 11:46:01 AM GMT+03:00, Joel Reicher<joel.reicher@gmail.com> wrote:
>Jean Louis <bugs@gnu.support> writes:
>
>> * Joel Reicher <joel.reicher@gmail.com> [2025-01-11 17:16]:
>
>[...]
>
>> Here’s a corrected version of your text:
>
>I'm not sure that what I said needed correcting, and even if it did, the corrections would need to be faithful to my original intent.

Oh, that's not related to you, it's my Emacs extension correcting the text that said to me that text was corrected. 

To me. 

Within my buffer, it talks too much. Anthropomorphizing it. 😉


Jean

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

RE: [External] : Exiting from mapc

[Drew Adams]

> How can one get  the result of the throw?  With a let?
> 
> > The Elisp manual makes great bedtime reading.
> > Time better spent than asking help-gnu-emacs,
> > perhaps.

Whatever you might mean by "get the result of the
throw", the answer's quoted just below your question.

You can't hope to progress if you don't read the
help that so many people have provided, in the
form of `C-h f' and the Elisp manual.  I led you
right to the water, but I can't make you drink,
no matter how thirsty you might be.

Anyway...

throw sends its result to catch, which returns
it as the value of the catch call.  Or as `C-h f'
tells you:

  "Throw to the catch for TAG and return VALUE from it."
                                  ^^^^^^^^^^^^^^^^^^^^

"it" = "the catch".

Re: [External] : Exiting from mapc

[Eduardo Ochs]

On Wed, 1 Jan 2025 at 20:15, Heime via Users list for the GNU Emacs
text editor <help-gnu-emacs@gnu.org> wrote:
>
> How can one get  the result of the throw?  With a let?

;; See: (info "(elisp)Catch and Throw")
(catch 'a (throw 'a 'b))

  Cheers,
    Eduardo

Re: [External] : Exiting from mapc

[Björn Bidar]

Drew Adams <drew.adams@oracle.com> writes:

>> How can I exit when encountering 'safg or 'nogo
>
> As usual, wrap with a `catch', and `throw' to it whenever you like.

Should dolist be better in this context anyway?

RE: [External] : Exiting from mapc

[Drew Adams]

> >> How can I exit when encountering 'safg or 'nogo
> >
> > As usual, wrap with a `catch', and `throw' to it whenever you like.
> 
> Should dolist be better in this context anyway?

Of course, but it doesn't answer his question. ;-)

If a plain iteration, with no intermediate escape
to throw a value, is appropriate for what you want
to do, then by all means use it.

IOW, don't go catching and throwing willy nilly.
Like `GO TO'.

`dolist' and `mapc' etc. don't let you escape;
you must go through the whole list.  Catch and
throw are available for when you need to get out
and return or do something directly, and not
waste time running down the rest of the list for
nothing.

Re: [External] : Exiting from mapc

[Björn Bidar]

Drew Adams <drew.adams@oracle.com> writes:

>> >> How can I exit when encountering 'safg or 'nogo
>> >
>> > As usual, wrap with a `catch', and `throw' to it whenever you like.
>> 
>> Should dolist be better in this context anyway?
>
> Of course, but it doesn't answer his question. ;-)

Sure I'm just saying this as an added comment. macp can be expensive
unless you invoke a handler for function anyway or use a mapc style
filter function such as seq-filter.

> If a plain iteration, with no intermediate escape
> to throw a value, is appropriate for what you want
> to do, then by all means use it.
>
> IOW, don't go catching and throwing willy nilly.
> Like `GO TO'.
>
> `dolist' and `mapc' etc. don't let you escape;
> you must go through the whole list.  Catch and
> throw are available for when you need to get out
> and return or do something directly, and not
> waste time running down the rest of the list for
> nothing.

Another approach is to use second status variable when using while.
Are there instances where a throw and catch does not work in while loop?

RE: [External] : Exiting from mapc

[Drew Adams]

> Are there instances where a throw and catch
> does not work in while loop?

Dunno what you have in mind by "does not work",
but no.

throw unilaterally transfers control to the
innermost catch that has the same TAG as the
throw.

But if there's no catch with that TAG then an
error is raised.  (Does that qualify for you
as not working?)

Re: [External] : Exiting from mapc

[Björn Bidar]

Drew Adams <drew.adams@oracle.com> writes:

> But if there's no catch with that TAG then an
> error is raised.  (Does that qualify for you
> as not working?)

By not working I meant that using throw and success in a C-like break
and that not working.

I wouldn't call your example not working but it is something to take
into account when coming from other languages.

RE: [External] : Exiting from mapc

[Drew Adams]

> > But if there's no catch with that TAG then an
> > error is raised.  (Does that qualify for you
> > as not working?)
> 
> By not working I meant that using throw and success in a C-like break
> and that not working.

Dunno the answer; sorry.  I've been on a C break
for about 40 years now, and plan to stay on it. ;-)
 
> I wouldn't call your example not working but it is something to take
> into account when coming from other languages.

Re: Exiting from mapc

[Jean Louis]

* Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2024-12-31 22:37]:
> 
> How can I exit when encountering 'safg or 'nogo 
> 
> (defun amazones-falkotr-kntlr (actm-seqr)
> 
>   (mapc
> 
>     (lambda (actm)
>       ;; Evaluate conditions and executes corresponding actions
>       ;; based on matching clauses.
> 
>       (cond
> 
>         ;; CASE
>         ((eq actm 'safg)
>            (message "SAFG amazones-falkotr-kntlr"))

To answer the message "How can I exit when encountering 'safg or
'nogo', yes, you can exit.

Here is what happens if there is no number 1 in the list here below:

(let ((list (catch 'no-go
  (mapc (lambda (item)
          (if (= item 1)
              (throw 'no-go nil)
            (message "Processing item: %S" item)))
        '(2 3 4 5 6)))))
list)  ➜ (2 3 4 5 6)

But if there is number one, `throw' exits:

(let ((list (catch 'no-go
  (mapc (lambda (item)
          (if (= item 1)
              (throw 'no-go nil)
            (message "Processing item: %S" item)))
        '(2 1 3 4 5 6)))))
list)
Processing item: 2
and finished there!

So yes, you can exit from mapc if you enclose it with `catch' this way.

-- 
Jean Louis

Did you finally exit from mapc?

[Jean Louis]

But Heime, did you finally exit from `mapc'? 😂

mapc is not Maybe Always Procrastinate Completely

I am waiting. ⏳

-- 
Jean Louis

Re: Did you finally exit from mapc?

[Heime via Users list for the GNU Emacs text editor]

Sent with Proton Mail secure email.

On Sunday, January 12th, 2025 at 2:48 AM, Jean Louis <bugs@gnu.support> wrote:

> But Heime, did you finally exit from `mapc'? 😂
> 
> mapc is not Maybe Always Procrastinate Completely
> 
> I am waiting. - Jean Louis

With a catch and throw

RE: [External] : Re: Did you finally exit from mapc?

[Drew Adams]

> > But Heime, did you finally exit from `mapc'? 😂
>
> With a catch and throw

Bingo!