Re: help-gnu-emacs Digest, Vol 265, Issue 12

Re: help-gnu-emacs Digest, Vol 265, Issue 12

[Marco Antoniotti]

Thank you Stefan

Looking at pq.el helps a lot (although it does not compile on my Mac;
include directory problem).

I also found out that I can name all my functions Common Lisp like with ':'
:) :) :)

All the best

Marco


On Tue, Dec 3, 2024 at 4:57 PM <help-gnu-emacs-request@gnu.org> wrote:

> Send help-gnu-emacs mailing list submissions to
>         help-gnu-emacs@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
> or, via email, send a message with subject or body 'help' to
>         help-gnu-emacs-request@gnu.org
>
> You can reach the person managing the list at
>         help-gnu-emacs-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of help-gnu-emacs digest..."
>
>
> Today's Topics:
>
>    1. Re: Advantage using mapc over dolist (Tomas Hlavaty)
>    2. Re: How to Display a Zero Height Line (Stefan Monnier)
>    3. Re: define-package, use-package and recipe: which ones?
>       (Stefan Monnier)
>    4. Re: Breaking indentation to the right side (Stefan Monnier)
>    5. Re: Regular expressions and user-escaped characters
>       (Stefan Monnier)
>    6. Re: Advantage using mapc over dolist (Stefan Monnier)
>    7. Re: Advantage using mapc over dolist (Tomas Hlavaty)
>    8. Re: Advantage using mapc over dolist (Tomas Hlavaty)
>    9. Re: Advantage using mapc over dolist (Tomas Hlavaty)
>   10. Re: Advantage using mapc over dolist (Tomas Hlavaty)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 03 Dec 2024 14:19:30 +0100
> From: Tomas Hlavaty <tom@logand.com>
> To: Heime <heimeborgia@protonmail.com>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,
>         help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <87r06oucnx.fsf@neko.mail-host-address-is-not-set>
> Content-Type: text/plain
>
> On Mon 02 Dec 2024 at 22:07, Tomas Hlavaty <tom@logand.com> wrote:
> > (defun tempo-is-user-element (element)
> >   "Try all the user-defined element handlers in `tempo-user-elements'."
> >   ;; Sigh... I need (some list)
> >   (catch 'found
> >     (mapc (lambda (handler)
> >             (let ((result (funcall handler element)))
> >               (if result (throw 'found result))))
> >         tempo-user-elements)
> >     (throw 'found nil)))
> >
> > although in Common Lisp, I would avoid catch, throw and mapc and used
> > dolist with return or return-from instead:
> >
> > (defun tempo-is-user-element (element)
> >   (dolist (handler tempo-user-elements)
> >     (let ((z (funcall handler element)))
> >       (when z
> >         (cl-return z)))))
> >
> > This is more readable than the catch, mapc, throw code in Emacs.
> >
> > Unfortunately, cl-return-from does not seems to be as convenient.
> > cl-return might do what I expect cl:return to be doing.
>
> and as the comment in tempo-is-user-element says, this is also nice
> example, how longing for "liberating feeling" leads to duplicating the
> same code all over the place, badly.  If only there was SOME in Emacs
> lisp instead of cl-lib?  Such a simple and useful function.  It even
> does not have keyword arguments.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 03 Dec 2024 08:30:22 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: How to Display a Zero Height Line
> Message-ID: <jwviks0gaie.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> > 3. The vertical space can be drawn at zero height and at fractional
> > heights up to the distance content is slid in from
>
> I think currently, you won't be able to get down to actual zero *except*
> by making that line `invisible`.
>
>
>         Stefan
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 03 Dec 2024 08:44:26 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: define-package, use-package and recipe: which ones?
> Message-ID: <jwvcyi8gac0.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> Marco Antoniotti [2024-12-01 09:43:02] wrote:
> > So.  I do not need to do anything (except remove my -pkg.el file from the
> > repo).
>
> That's right, assuming you already have an `Author:` (or `Maintainer:`)
> with a valid email address, and you maintain a `Version:` header
> as well.
>
> >    1. where should I put the 'recipe' file?
>
> What recipe file?  If you're referring to the data used to tell where to
> find your repository, that's something maintained on the side of the
> ELPA archive (e.g. Melpa or (Non)GNU ELPA) and each archive does
> it differently.
>
> >    2. what is `use-package` used for then?
>
> It's an alternative style to write Emacs init files.
>
> >    3. One of the two packages I want to submit builds an emacs module;
> any
> >    suggestions about how to package it?
>
> I'd suggest you look at [libpq](http://elpa.gnu.org/packages/pq.html),
> which is a package with similar needs (and with virtually zero ELisp
> code of its own).  It all starts in the `pq.el` file which doesn't do
> much more than arrange to compile the module.
>
>
>         Stefan
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 03 Dec 2024 08:47:08 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Breaking indentation to the right side
> Message-ID: <jwv7c8gg9r7.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> > Keeping with an 80 column width, would it be  acceptable to change the
> > indentation for section  to start from some left side position rather
> > than continuing with the indentation towards the  right side?
>
> That would be poor style.
> The deeply indented code is usually a strong sign that you should cut
> your code into smaller pieces that you place in separate functions.
>
>
>         Stefan
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 03 Dec 2024 09:01:01 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Regular expressions and user-escaped characters
> Message-ID: <jwv1pyog9ek.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> > Hi, what do you do in a regular expression if you want to match a
> character,
> > but not a the same character that has been escaped by the user. E.g., if
> > I want my regular expression to look for ?\[ (ASCII 91), matching string
> "["
> > and "a[a" but not string "\\[" or "a\\[a", if you follow me. Is this
> > possible with just a regular expression?
>
> The "usual" way we do that is with the godawful:
>
>     "\\(?:^\\|[^\\]\\(?:\\\\\\\\\\)*\\)\\["
>
> This is careful to match the [ if it's preceded by an even number
> of backslashes.  But beware that it makes more than the actual [, so if
> you start the search from a point that's looking at a [, it won't find
> it (except if it's at the beginning of the line).
>
> > If not, what is a good workaround?
>
> Just use a regexp which matches all [ (regardless of any previous
> backslashes) and then check afterwards, in ELisp, whether it's preceded
> by an odd number of backslashes, e.g. with something like
>
>     (save-excursion
>       (goto-char <FOO>)
>       (zerop (% (skip-chars-backward "\\") 2)))
>
>
> - Stefan
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 03 Dec 2024 09:11:08 -0500
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <jwvv7w0eu7m.fsf-monnier+emacs@gnu.org>
> Content-Type: text/plain
>
> >>           (pcase actm
> >>            ('armg (do-this))
> >>            ('go (do-that))))
> >
> > this does not justify pcase, use ecase or case instead
>
> That's your personal preference.
> My own personal preference is to forget about
> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> already did.
>
> There's no need to "justify" the use of `pcase` for simple cases any
> more than there's a need to justify the use of Emacs for trivial edits.
>
>
>         Stefan
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 03 Dec 2024 15:48:16 +0100
> From: Tomas Hlavaty <tom@logand.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>,  help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <87o71su8jz.fsf@neko.mail-host-address-is-not-set>
> Content-Type: text/plain
>
> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >>>           (pcase actm
> >>>            ('armg (do-this))
> >>>            ('go (do-that))))
> >>
> >> this does not justify pcase, use ecase or case instead
> >
> > That's your personal preference.
> > My own personal preference is to forget about
> > case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> > already did.
> >
> > There's no need to "justify" the use of `pcase` for simple cases any
> > more than there's a need to justify the use of Emacs for trivial edits.
>
> on the contrary, it is better to use specific tools and avoid more
> general tools when possible in order to lower cognitive load.
>
> also the more general a tool is the less useful other orthogonal tools
> become.  see how much nicer eldoc is with cl-case and cl-ecase?
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 03 Dec 2024 15:59:36 +0100
> From: Tomas Hlavaty <tom@logand.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>,  help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <87h67ku813.fsf@neko.mail-host-address-is-not-set>
> Content-Type: text/plain
>
> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >>>           (pcase actm
> >>>            ('armg (do-this))
> >>>            ('go (do-that))))
> >>
> >> this does not justify pcase, use ecase or case instead
> >
> > That's your personal preference.
> > My own personal preference is to forget about
> > case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> > already did.
>
> I respect your preference and understand that you as pcase author would
> prefer it everywhere.  But whoever renamed case and ecase did not
> respect other peoples preferences and people are now forced to use that
> pcase monstrosity even in very simple cases.
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 03 Dec 2024 16:40:03 +0100
> From: Tomas Hlavaty <tom@logand.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>,  help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <87ed2ou65o.fsf@neko.mail-host-address-is-not-set>
> Content-Type: text/plain
>
> On Tue 03 Dec 2024 at 15:59, Tomas Hlavaty <tom@logand.com> wrote:
> > On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >>>>           (pcase actm
> >>>>            ('armg (do-this))
> >>>>            ('go (do-that))))
> >>>
> >>> this does not justify pcase, use ecase or case instead
> >>
> >> That's your personal preference.
> >> My own personal preference is to forget about
> >> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> >> already did.
> >
> > I respect your preference and understand that you as pcase author would
> > prefer it everywhere.  But whoever renamed case and ecase did not
> > respect other peoples preferences and people are now forced to use that
> > pcase monstrosity even in very simple cases.
>
> ecase comes from here:
>
>    commit fcd737693e8e320acd70f91ec8e0728563244805
>    Author: Richard M. Stallman <rms@gnu.org>
>    Date:   Fri Jul 30 20:15:09 1993 +0000
>
>        entered into RCS
>
> renamed to cl-ecase here:
>
>    commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf
>    Author: Stefan Monnier <monnier@iro.umontreal.ca>
>    Date:   Sun Jun 3 21:05:17 2012 -0400
>
> pcase comes from here:
>
>    commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd
>    Author: Stefan Monnier <monnier@iro.umontreal.ca>
>    Date:   Tue Aug 10 15:18:14 2010 +0200
>
>        * lisp/emacs-lisp/pcase.el: New file.
>
> Not very nice to dismiss other peoples preferences as "just your
> personal preference" while pushing through your personal preference.
> That ecase macro was there for many decades, even before import to RCS
> and you broke it and force your pcase way on everybody.  The author used
> pcase because of you, not very good argument for pcase merit.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 03 Dec 2024 16:57:10 +0100
> From: Tomas Hlavaty <tom@logand.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>,  help-gnu-emacs@gnu.org
> Subject: Re: Advantage using mapc over dolist
> Message-ID: <87a5dcu5d5.fsf@neko.mail-host-address-is-not-set>
> Content-Type: text/plain
>
> On Tue 03 Dec 2024 at 16:40, Tomas Hlavaty <tom@logand.com> wrote:
> > On Tue 03 Dec 2024 at 15:59, Tomas Hlavaty <tom@logand.com> wrote:
> >> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> >>>>>           (pcase actm
> >>>>>            ('armg (do-this))
> >>>>>            ('go (do-that))))
> >>>>
> >>>> this does not justify pcase, use ecase or case instead
> >>>
> >>> That's your personal preference.
> >>> My own personal preference is to forget about
> >>> case/cl/case/ecase/cl-ecase and just use `pcase` like the author
> >>> already did.
> >>
> >> I respect your preference and understand that you as pcase author would
> >> prefer it everywhere.  But whoever renamed case and ecase did not
> >> respect other peoples preferences and people are now forced to use that
> >> pcase monstrosity even in very simple cases.
> >
> > ecase comes from here:
> >
> >    commit fcd737693e8e320acd70f91ec8e0728563244805
> >    Author: Richard M. Stallman <rms@gnu.org>
> >    Date:   Fri Jul 30 20:15:09 1993 +0000
> >
> >        entered into RCS
> >
> > renamed to cl-ecase here:
> >
> >    commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf
> >    Author: Stefan Monnier <monnier@iro.umontreal.ca>
> >    Date:   Sun Jun 3 21:05:17 2012 -0400
> >
> > pcase comes from here:
> >
> >    commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd
> >    Author: Stefan Monnier <monnier@iro.umontreal.ca>
> >    Date:   Tue Aug 10 15:18:14 2010 +0200
> >
> >        * lisp/emacs-lisp/pcase.el: New file.
> >
> > Not very nice to dismiss other peoples preferences as "just your
> > personal preference" while pushing through your personal preference.
> > That ecase macro was there for many decades, even before import to RCS
> > and you broke it and force your pcase way on everybody.  The author used
> > pcase because of you, not very good argument for pcase merit.
>
> And now thanks to pcase there is also cond*.
> What a mess.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>
>
> ------------------------------
>
> End of help-gnu-emacs Digest, Vol 265, Issue 12
> ***********************************************
>


-- 
Marco Antoniotti
Somewhere over the Rainbow

Re: help-gnu-emacs Digest, Vol 265, Issue 12

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

> Looking at pq.el helps a lot (although it does not compile on my Mac;
> include directory problem).

We don't have much experience with such "packages with modules".
I pointed you to `pq` because that's the one with which I'm familiar,
but it's not been heavily tested.  So bug fixes (or bug
reports) welcome.


        Stefan