Eli Zaretskii writes: >> From: Ruijie Yu >> Cc: Eli Zaretskii , asjo@koldfront.dk >> Date: Thu, 09 Feb 2023 00:48:15 +0800 >> >> Here is a preliminary patch that contains some "REVIEW" comments where I >> need inputs. > > Thanks, but could you perhaps post diffs disregarding the whitespace > changes? That would make it easier to review the real changes. Thanks, done. >> -(defun archive-*-write-file-member (archive descr command) >> +;; REVIEW: is there a better name than AVOID-EXTLESS-P? >> +(defun archive-*-write-file-member (archive descr command >> + &optional avoid-extless-p) > > ensure-extension? That sounds better, and I have renamed the variable in this iteration. >> + ;; REVIEW: the diff here is because the previous code had TAB's >> + ;; (while assuming each TAB is 4 spaces), and my Emacs replaced >> + ;; them with spaces. What is the status quo on this kind of diff? >> + ;; I can remove them if we consider this change excessive and/or >> + ;; intrusive. > > TABs in Emacs are by default 8 columns, not 4. > > It is OK to convert TABs to spaces when changing the code in Lisp, but > please do that only for the last commit, to make the review process > easier. For all the draft versions, please use "git diff" options > that cause Git to ignore changes in whitespace. > > Thanks. Thanks, I will keep that in mind. I have also made some rearrangements in the code to minimize delta. In addition, I fixed an issue from the first iteration: in the first iteration, the user would be prompted to revert buffer from disk if the rename was in action; in this iteration this should no longer be the case -- that is, the user should expect no difference between filenames with extensions and without. As pointed out in the commit message, two things remain: to ensure that all write operations to extensionless zip archives behave correctly, and to have some way to test that things continue to work in the future.