bug-gnu-emacs
[Top][All Lists]
Advanced

[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.

Attachment: 0001-lisp-arc-mode.el-Work-around-zip-s-filename-limitati.patch
Description: Text Data

Best,


RY

reply via email to

[Prev in Thread] Current Thread [Next in Thread]