GNU bug report logs - #61326
30.0.50; Editing fil in zip file without extension save creates new file

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: asjo <at> koldfront.dk, 61326 <at> 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

> From: Ruijie Yu <ruijie <at> netyu.xyz>
> Cc: asjo <at> koldfront.dk, 61326 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.