bug#67926: 29.1; fail to extract ZIP subfile named with [...]

[Eli Zaretskii <eliz@gnu.org>]

> From: awrhygty@outlook.com
> Cc: 67926@debbugs.gnu.org
> Date: Thu, 28 Dec 2023 09:38:57 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If unzip.exe(or an alternative external program) is necessary,
> >> I want emacs not to load contents of archive files into archive-mode
> >> buffer. It is waste of time and memory.
> >
> > unzip is necessary to extract files, but not to display the archive's
> > contents.
> 
> If users are expected to have unzip.exe, emacs can list subfiles without
> examining archive contents as a binary file.
> Users with unzip.exe don't care about whether subfiles are listed with
> unzip.exe or not.

I see your point.  However, those decisions were made many years ago,
and have withstood the test of time since then.  So I see no reason to
make drastic changes in how we support zip archives, just because we
can, or just because other arrangements are possible.

> If users are not expected to have unzip.exe, they feel convenient if
> subfiles are extracted without unzip.exe.
> In this case, it is better archive-zip-extract's value as variable can
> be a lisp function to be called in the archive-zip-extract function.

We could consider extracting using our own code if someone writes the
code to support all the 17 methods that unzip.exe supports.
Otherwise, we would introduce a regression, and someone somewhere will
rightfully complain.

Btw, your suggested changes required gzip and bunzip2 as external
programs to support the 2 most popular compression methods.  Why
should we assume these are available more widely than unzip,
especially on Windows?