Eli Zaretskii writes: > [...] >> By the way, while writing tests, I see a need to modify >> `archive-expunge' to accept an additional optional argument FORCE acting >> as the prefix argument. I suppose if this is favored, I should probably >> say something in the etc/NEWS file (as well as the docstring, and maybe >> an info page somewhere)? FTR, previously prefix arguments are ignored >> for `archive-expunge'. >> >> The reason for the need of a FORCE argument is so that I want to ensure >> that file contents are correct after deleting a member using >> archive-mode functionalities without getting prompted for confirmation. >> However, `archive-expunge' ATM requires a user prompt via its baked-in >> `yes-or-no-p' call. > > This is a separate feature. [...] So if we are going to treat > archive-expunge differently, I think we'll need a very good reason. I see, thanks for explaining. 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. 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. FTR, I ran `make check' and ensured that my changes didn't introduce regressions, while also noticed that some tests in vc and eglot fail both before and after my changes.