[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61326: [DRAFT PATCH v2] Work around zip's filename extension limitat
From: |
Ruijie Yu |
Subject: |
bug#61326: [DRAFT PATCH v2] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch) |
Date: |
Fri, 10 Feb 2023 16:40:25 +0800 |
User-agent: |
mu4e 1.8.13; emacs 29.0.60 |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Ruijie Yu <ruijie@netyu.xyz>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 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.
0001-lisp-arc-mode.el-Work-around-zip-s-filename-limitati.patch
Description: Text Data
Best,
RY
- bug#61326: 30.0.50; Editing fil in zip file without extension save creates new file, Adam Sjøgren, 2023/02/06
- bug#61326: 30.0.50; Editing fil in zip file without extension save creates new file, Eli Zaretskii, 2023/02/06
- bug#61326: Adding --no-add-suffix to zip patch, Adam Sjøgren, 2023/02/06
- bug#61326: Adding --no-add-suffix to zip patch, Ruijie Yu, 2023/02/06
- bug#61326: Adding --no-add-suffix to zip patch, Eli Zaretskii, 2023/02/06
- bug#61326: Adding --no-add-suffix to zip patch, Ruijie Yu, 2023/02/07
- bug#61326: Adding --no-add-suffix to zip patch, Eli Zaretskii, 2023/02/07
- bug#61326: [DRAFT PATCH] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch), Ruijie Yu, 2023/02/08
- bug#61326: [DRAFT PATCH] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch), Eli Zaretskii, 2023/02/08
- bug#61326: [DRAFT PATCH v2] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch),
Ruijie Yu <=
- bug#61326: [DRAFT PATCH v3] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch), Ruijie Yu, 2023/02/13
- bug#61326: Adding --no-add-suffix to zip patch, Adam Sjøgren, 2023/02/07
- bug#61326: Adding --no-add-suffix to zip patch, Ruijie Yu, 2023/02/07
- bug#61326: Adding --no-add-suffix to zip patch, Eli Zaretskii, 2023/02/07