From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Marco Antoniotti Newsgroups: gmane.emacs.help Subject: Re: help-gnu-emacs Digest, Vol 265, Issue 12 Date: Tue, 3 Dec 2024 17:27:45 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14298"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 03 17:28:41 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIVlR-0003ZV-C1 for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 03 Dec 2024 17:28:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIVkv-0006Yk-6R; Tue, 03 Dec 2024 11:28:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIVkq-0006YP-6G for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 11:28:04 -0500 Original-Received: from mail-yb1-xb2e.google.com ([2607:f8b0:4864:20::b2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tIVkl-0007zF-EV for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 11:28:03 -0500 Original-Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-e39a1af8379so358038276.0 for ; Tue, 03 Dec 2024 08:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733243277; x=1733848077; darn=gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=NbCjrEHak76oFYmh6penaIkEO+AkSbddI0ROCeXJGCE=; b=N6IW439jjMqIh73aI1XmETaJH69SrbxOa7xaXzCv2B4mvaeSq/LnO1TdeRruEskX2L 0ti9dAPw4Z5KjPhYa3/yY6k6fel/3wlK/RxwDPJ7zxF1cX2Bz2R5JdOKOAc6H8jRqETz 8AJlc48hwUXnxEpe6DX8R5tLyc2rIjhRUuaMgMmjhW/M2/0upeXbK3cKcJB/XIpJ+sQq AXSv507Anz/w0adgjW3X3umpaaZAI0WLsdpAjaxsyOdbUWVUFhdAcr3LuhK+N4X5kXnA OHQpGk992DhLK2yyVSA4iG/NCILZfXUwuN9BPwBAcaU5BFdfsazpIY28u65bLIku++I9 lJLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733243277; x=1733848077; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NbCjrEHak76oFYmh6penaIkEO+AkSbddI0ROCeXJGCE=; b=lJLLOm5o5ooY7faD6A8rhHODfD++T6QFFCGBUDsFPeIvpdId58lPpjPke5HikxNKWG 8rFc0e2LvJdIuuab7caDsSn6yos6K4ounW2wsik1R1lAQMqhvvAzswkvpZLhxpHfnX2V XggjePnQxSWfZT3JtziBibUe0ipK4D3KltF2cL7Rzb6xLHuhU5bw2nWWF90tfKjxzIwU MvN4CPViIxh/sP2iMAZU0MS2yGDQHgYUaM8XcV/gfG9xyizBUF6S2IDmj1JOFOY/0bv+ paUyvkN/f+X+qI2gnBSRn9340t594Y4qdSrjVCNOH5o5E622Qzau1VUhrTzv4gXU21MH YzDQ== X-Gm-Message-State: AOJu0YzBUSJRtXeY5GosISY1KtPUFbBMsqlrCaOijhrIUnzX4LRIMvwy L5VT/ERI2Ym4UNLIb1mnl65SdAqss79Nw/TLvNjDzxSm78bpizSHa0CgXRu1+z0sd9Fa1n7xWz8 5kXr+PduKrFEaaCWPMrO6Ux/NIOTsx130 X-Gm-Gg: ASbGncs9q1Vi0v80RyAmJweUo7rYple7hLWs7wIvo+I4UhqsxiOL9PMcuWyM0cftwVO inNNLs1446dPyLKGljMQdAX5Vm0FPjo8= X-Google-Smtp-Source: AGHT+IG1f6hrxGimLvK8whAWElvlpp+wmBkolm/nkEgLIAqTx1ZlR/mYsvQ446ceoJG9zJw7GAa3om0pSTsAZo4gGFU= X-Received: by 2002:a05:6902:2784:b0:e39:73bf:f762 with SMTP id 3f1490d57ef6-e39d39ec8eemr1035181276.2.1733243276728; Tue, 03 Dec 2024 08:27:56 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b2e; envelope-from=marcoxa@gmail.com; helo=mail-yb1-xb2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148539 Archived-At: 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=E2=80=AFPM wro= te: > 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 > To: Heime > Cc: Michael Heerdegen , > 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 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 > To: help-gnu-emacs@gnu.org > Subject: Re: How to Display a Zero Height Line > Message-ID: > 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 > To: help-gnu-emacs@gnu.org > Subject: Re: define-package, use-package and recipe: which ones? > Message-ID: > 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 t= he > > 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 > To: help-gnu-emacs@gnu.org > Subject: Re: Breaking indentation to the right side > Message-ID: > 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 > To: help-gnu-emacs@gnu.org > Subject: Re: Regular expressions and user-escaped characters > Message-ID: > 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., i= f > > I want my regular expression to look for ?\[ (ASCII 91), matching strin= g > "[" > > 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 ) > (zerop (% (skip-chars-backward "\\") 2))) > > > - Stefan > > > > > ------------------------------ > > Message: 6 > Date: Tue, 03 Dec 2024 09:11:08 -0500 > From: Stefan Monnier > To: help-gnu-emacs@gnu.org > Subject: Re: Advantage using mapc over dolist > Message-ID: > 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 > To: Stefan Monnier , 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 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 > To: Stefan Monnier , 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 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 > To: Stefan Monnier , 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 wrote: > > On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU > Emacs text editor 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 > Date: Fri Jul 30 20:15:09 1993 +0000 > > entered into RCS > > renamed to cl-ecase here: > > commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf > Author: Stefan Monnier > Date: Sun Jun 3 21:05:17 2012 -0400 > > pcase comes from here: > > commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd > Author: Stefan Monnier > 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 > To: Stefan Monnier , 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 wrote: > > On Tue 03 Dec 2024 at 15:59, Tomas Hlavaty wrote: > >> On Tue 03 Dec 2024 at 09:11, Stefan Monnier via Users list for the GNU > Emacs text editor 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 woul= d > >> prefer it everywhere. But whoever renamed case and ecase did not > >> respect other peoples preferences and people are now forced to use tha= t > >> pcase monstrosity even in very simple cases. > > > > ecase comes from here: > > > > commit fcd737693e8e320acd70f91ec8e0728563244805 > > Author: Richard M. Stallman > > Date: Fri Jul 30 20:15:09 1993 +0000 > > > > entered into RCS > > > > renamed to cl-ecase here: > > > > commit 7c1898a7b93053cd0431f46f02d82c0a31bfb8bf > > Author: Stefan Monnier > > Date: Sun Jun 3 21:05:17 2012 -0400 > > > > pcase comes from here: > > > > commit d02c9bcd096c44b4e3d5e2834c75967b56cdecdd > > Author: Stefan Monnier > > 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 use= d > > 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 > *********************************************** > --=20 Marco Antoniotti Somewhere over the Rainbow