* Re: help-gnu-emacs Digest, Vol 265, Issue 12
[not found] <mailman.22124.1733241439.21403.help-gnu-emacs@gnu.org>
@ 2024-12-03 16:27 ` Marco Antoniotti
2024-12-04 2:16 ` Stefan Monnier via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 2+ messages in thread
From: Marco Antoniotti @ 2024-12-03 16:27 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 2+ messages in thread