unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ruijie Yu <ruijie@netyu.xyz>
Cc: asjo@koldfront.dk, 61326@debbugs.gnu.org
Subject: bug#61326: [DRAFT PATCH v4] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch)
Date: Sat, 11 Mar 2023 10:54:36 +0200	[thread overview]
Message-ID: <834jqry8fn.fsf@gnu.org> (raw)
In-Reply-To: <sdvv8jesczg.fsf@fw.net.yu> (message from Ruijie Yu on Mon, 06 Mar 2023 12:05:23 +0800)

> From: Ruijie Yu <ruijie@netyu.xyz>
> Cc: asjo@koldfront.dk, 61326@debbugs.gnu.org
> Date: Mon, 06 Mar 2023 12:05:23 +0800
> 
> In the attached patches I followed the alternative approach which I
> described in my previous message: take the meat of the function into a
> separate helper function, and use that in the `archive-expunge' function
> and in my new test.  If someone else has a good reason for using prefix
> argument to "force" deletion, they can ask in a new bug report.
> 
> Another question regarding this change: when moving `archive-expunge'
> into `archive--expunge-maybe-force', I rewrote the portion that
> populates the list of files that are marked for deletion.  Originally it
> was using `while' + `setq', and seeing that arc-mode.el already requires
> `cl-lib', I turned it into a `cl-do' construct.  Do people have a
> preference or does it matter?  I can change this portion back to the
> original if there's objection.

I don't object in principle, but in this case it looks like the
implementation based on cl-do needs much more complex code than the
original?  If so, I'd prefer the original, simpler and
easier-to-understand code.

> To ease the review process, I have broken down the changes into two
> patch files.  The first one is merely to take out `archive-expunge' into
> helper function `archive--expunge-maybe-force', and the second one is
> everything else, including the tests.
> 
> The goal for the final patch is to combine these two into one, to make
> necessary indentation changes around the portions that I touched, and to
> only use the commit message of the second patch _verbatim_ -- so please
> verify that this commit message is satisfactory in emacs.git, thanks.

The commit log message is not detailed enough: it doesn't mention the
functions you modify.  Please see the conventions we follow for log
messages described in CONTRIBUTE, which also mentions useful Emacs
functions which will help you format the log message according to our
conventions.

Thanks.





  reply	other threads:[~2023-03-11  8:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 17:00 bug#61326: 30.0.50; Editing fil in zip file without extension save creates new file Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-06 18:04 ` Eli Zaretskii
2023-02-06 18:15   ` Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-06 18:57 ` bug#61326: Adding --no-add-suffix to zip patch Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-07  1:31   ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-07  3:27     ` Eli Zaretskii
2023-02-07 13:53       ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-07 14:54         ` Eli Zaretskii
2023-02-08 16:48         ` bug#61326: [DRAFT PATCH] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch) Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-08 18:02           ` Eli Zaretskii
2023-02-10  8:40             ` bug#61326: [DRAFT PATCH v2] " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-13 10:35               ` bug#61326: [DRAFT PATCH v3] " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-04 11:21                 ` Eli Zaretskii
2023-03-04 14:56                   ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-04 15:12                     ` Eli Zaretskii
2023-03-05 15:23                       ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-05 15:52                         ` Eli Zaretskii
2023-03-06  4:05                           ` bug#61326: [DRAFT PATCH v4] " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11  8:54                             ` Eli Zaretskii [this message]
2023-03-11  8:57                               ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-17  3:19                                 ` bug#61326: [DRAFT PATCH v5] " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-17  8:48                                   ` bug#61326: [PATCH " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-20  7:47                                     ` Eli Zaretskii
2023-04-20  8:49                                       ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-20  9:29                                         ` Eli Zaretskii
2023-02-07 19:59     ` bug#61326: Adding --no-add-suffix to zip patch Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-08  1:21       ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-08  3:28         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834jqry8fn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=61326@debbugs.gnu.org \
    --cc=asjo@koldfront.dk \
    --cc=ruijie@netyu.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).