tgz extension and dired-do-compress

tgz extension and dired-do-compress

[Uwe Brauer]

 
Hi   The setting of the variable    dired-filetype-compress-regexp 
is a variable defined in ‘dired-filetype-face.el’.  Its value is 
("7Z" "7z" "apk" "bz2" "bzip2" "cab" "deb" "ear" "gpg" "gz" "gzip" 
"img" "iso" "jar" "lzma" "pkg" "RAR" "rar" "rpm" "tar" "taz" 
"tbz2" "tgz" "txz" "war" "wim" "XAR" "xar" "XZ" "xz" "Z" "z" "ZIP" 
"zip") 
 
So tgz is included. 
 
 
However whenever I try to run dired-do-compress on a tgz archive it is 
not uncompressed to a tar archive. What do I miss? 
 
It seems that this feature is missing.

Uwe Brauer 

Re: tgz extension and dired-do-compress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue, 13 Nov 2018 14:18:21 +0100
> 
>  
> Hi   The setting of the variable    dired-filetype-compress-regexp 
> is a variable defined in ‘dired-filetype-face.el’.  Its value is 

That's not the variable relevant to dired-do-compress.  But that's not
your problem, as the variable dired-compress-file-suffixes also
includes .tgz.

> However whenever I try to run dired-do-compress on a tgz archive it is 
> not uncompressed to a tar archive. What do I miss? 

I don't know, because it works for me.  Did you try in "emacs -Q"?

Re: tgz extension and dired-do-compress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Uwe Brauer <oub@mat.ucm.es>
   >> Date: Tue, 13 Nov 2018 14:18:21 +0100
   >> 
   >> 
   >> Hi   The setting of the variable    dired-filetype-compress-regexp 
   >> is a variable defined in ‘dired-filetype-face.el’.  Its value is 

   > That's not the variable relevant to dired-do-compress.  But that's not
   > your problem, as the variable dired-compress-file-suffixes also
   > includes .tgz.

   >> However whenever I try to run dired-do-compress on a tgz archive it is 
   >> not uncompressed to a tar archive. What do I miss? 

   > I don't know, because it works for me.  Did you try in "emacs -Q"?


It works for me using emacs -Q.

However with my init files loaded,  when I run Z in a dired buffer, the
tgz package gets extracted, not only uncompressed as it does when
starting emacs -Q

Strangely enough 
,----
| 
| Z runs the command dired-do-compress (found in dired-mode-map), which
| is an interactive autoloaded compiled Lisp function in ‘dired-aux.el’.
| 
| It is bound to Z, <menu-bar> <operate> <compress>.
| 
| (dired-do-compress &optional ARG)
| 
| Compress or uncompress marked (or next ARG) files.
| 
`----

And dired-aux.el is in 

Library is file /opt/emacs27/share/emacs/27.0.50/lisp/dired-aux.elc

So I am really confused, something got redefined, defadvice, but usually
the help would tell me if that function is adviced. Very strange 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

[emacs -q versus empty .emacs file] (was: tgz extension and dired-do-compress)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   > I don't know, because it works for me.  Did you try in "emacs -Q"?


I also  tried out emacs -q and it works as expected, but when I start
emacs 


with a .emacs file which is empty the behavior of dired changes, so
something is loaded but what?

According to man emacs: emacs -q just does not load the init file

So why does not emacs -q and an empty .emacs file show the same behavior?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

[found the culprit] (was: [emacs -q versus empty .emacs file])

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer <oub@mat.ucm.es> writes:

>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
   >> I don't know, because it works for me.  Did you try in "emacs -Q"?


 When I run emacs -Q it works as you say, but emacs -Q calls the one
 Ubuntu provides, which is 25, I am using a compiled git master version

So with 

 /opt/emacs27/bin/emacs -Q

The behavior of Z in dired is new in emacs 17; it does not uncompress a tgz to tar,
but extract the whole compressed tar, which is a different behavior.

Re: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Noam Postavsky]

On Wed, 14 Nov 2018 at 07:17, Uwe Brauer <oub@mat.ucm.es> wrote:

> it does not uncompress a tgz to tar,
> but extract the whole compressed tar

This is the kind of thing you should say up front, insead of "it is
not uncompressed".

Anyway, this is Bug#25611.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25611

Re: [found the culprit]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

>>> "Noam" == Noam Postavsky <npostavs@gmail.com> writes:

   > On Wed, 14 Nov 2018 at 07:17, Uwe Brauer <oub@mat.ucm.es> wrote:
   >> it does not uncompress a tgz to tar,
   >> but extract the whole compressed tar

   > This is the kind of thing you should say up front, insead of "it is
   > not uncompressed".
Sorry, you are right.

   > Anyway, this is Bug#25611.

So it seems that the bug is still not solved?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Wed, 14 Nov 2018 13:12:38 +0100
> 
>  When I run emacs -Q it works as you say, but emacs -Q calls the one
>  Ubuntu provides, which is 25, I am using a compiled git master version
> 
> So with 
> 
>  /opt/emacs27/bin/emacs -Q
> 
> The behavior of Z in dired is new in emacs 17; it does not uncompress a tgz to tar,
> but extract the whole compressed tar, which is a different behavior.

It seems I misunderstood your original report: you wanted Z on a .tgz
file to only uncompress it?  That indeed has been changed in Emacs 26,
for consistency with a .tar.gz file.  I don't think it's a good idea
to have the previous subtle difference back.

I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
file, should not by default unpack the archive.  We could have a
special prefix arg to request that, and by default we should just
uncompress the file.  But that's a different issue.

Re: [found the culprit]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]



   > It seems I misunderstood your original report: you wanted Z on a .tgz
   > file to only uncompress it?  

Yes! Either Z or any other letter or combination.

   > That indeed has been changed in Emacs 26, for consistency with a
   > .tar.gz file. I don't think it's a good idea to have the previous
   > subtle difference back.

   > I do think that Z on a compressed Tar archive, be it a .tar.gz or
   > .tgz file, should not by default unpack the archive. We could have
   > a special prefix arg to request that, and by default we should just
   > uncompress the file. But that's a different issue.

So I am confused now. What is you personal preference?

  Z: tgz (tar.gz)--> tar

Or 

 Z: tgz (tar.gz)--> unpack

I would prefer to have both actions, say   

Z: tgz (tar.gz)--> tar and 
prefix+Z  tgz (tar.gz)--> unpack

Or the other way around.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: [found the culprit]

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Wed, 14 Nov 2018 16:49:09 +0100
> 
>    > I do think that Z on a compressed Tar archive, be it a .tar.gz or
>    > .tgz file, should not by default unpack the archive. We could have
>    > a special prefix arg to request that, and by default we should just
>    > uncompress the file. But that's a different issue.
> 
> So I am confused now. What is you personal preference?
> 
>   Z: tgz (tar.gz)--> tar
> 
> Or 
> 
>  Z: tgz (tar.gz)--> unpack

The former by default, the latter optionally.

Re: [found the culprit]

[Stefan Monnier]

> It seems I misunderstood your original report: you wanted Z on a .tgz
> file to only uncompress it?  That indeed has been changed in Emacs 26,
> for consistency with a .tar.gz file.  I don't think it's a good idea
> to have the previous subtle difference back.

Agreed.

> I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
> file, should not by default unpack the archive.  We could have a
> special prefix arg to request that, and by default we should just
> uncompress the file.  But that's a different issue.

FWIW, I consider ".tar.gz" (or "tar.lz", ...) as the archive format
(rather than as a combination of tar and compression): since the tar
format does not support random access anyway there's very little benefit
to having it uncompressed (unless the content can't be compressed
e.g. because it's already compressed).


        Stefan

Re: [found the culprit]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

   >> It seems I misunderstood your original report: you wanted Z on a .tgz
   >> file to only uncompress it?  That indeed has been changed in Emacs 26,
   >> for consistency with a .tar.gz file.  I don't think it's a good idea
   >> to have the previous subtle difference back.

   > Agreed.

   >> I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
   >> file, should not by default unpack the archive.  We could have a
   >> special prefix arg to request that, and by default we should just
   >> uncompress the file.  But that's a different issue.

   > FWIW, I consider ".tar.gz" (or "tar.lz", ...) as the archive format
   > (rather than as a combination of tar and compression): since the tar
   > format does not support random access anyway there's very little benefit
   > to having it uncompressed (unless the content can't be compressed
   > e.g. because it's already compressed).

Unfortunately some sites require to upload files in tar format and not in
tar.gz format. 

If I understand the current situation correctly, there is no key
combination or interactive function which would allow to just uncompress
a tgz (tar.gz) file? The only option is to use the
dired-do-shell-command?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

RE: [found the culprit]

[Drew Adams]

>> FWIW, I consider ".tar.gz" (or "tar.lz", ...) as the archive
>> format (rather than as a combination of tar and compression):
>> since the tar format does not support random access anyway
>> there's very little benefit to having it uncompressed (unless
>> the content can't be compressed e.g. because it's already compressed).
> 
> Unfortunately some sites require to upload files in tar format and not
> in tar.gz format.

Yes.  Upload, download, email...  It's quite possible for
a user to obtain a tar file, regardless of whether Stefan -
or even everyone here - considers tar.gz to be the only
useful archive format.

The question is whether `Z' should support tar files.

If so, a second question could be whether to have
another command that supports only tar.gz (or "tar.lz",
tgz, ...) files.

> If I understand the current situation correctly, there is no key
> combination or interactive function which would allow to just
> uncompress a tgz (tar.gz) file? The only option is to use the
> dired-do-shell-command?

I guess so.  One person's enhancement can be another
person's annoyance.

Re: [found the culprit]

[Stefan Monnier]

>> Unfortunately some sites require to upload files in tar format and not
>> in tar.gz format.

Something like Dired's `Z` can't satisfy all imaginable cases, so the
fact some odd cases require the generation of uncompressed .tar file
shouldn't make much a difference in deciding what behavior we want.

> Yes.  Upload, download, email...  It's quite possible for
> a user to obtain a tar file, regardless of whether Stefan -

The question is not "what do we do when we receive an uncompressed tar
file", but rather "what do we do when we have a compressed tar file" and
"what do we do when the user requests to compress a directory".

> or even everyone here - considers tar.gz to be the only
> useful archive format.

Noone said tar.gz is the only useful format.  I just pointed out that in
my experience ".tar.gz" is itself considered as an archive format rather
than "a compressed file which contains an archive" in the sense that in
the vast majority of cases people take a directory and pack it up into
a .tar.gz "tarball" or take a ".tar.gz" and unpack it into a directory
tree: the cases where the .tar intermediate step is used explicitly are
much less frequent.

> The question is whether `Z' should support tar files.

No.  It does and has done so for a long time and there's no suggestion
to make it stop supporting it.

And indeed Dired's `Z` has been compressing directories to tar.gz and
uncompressing tar.gz to directories (rather than to tar files) for many
years now.


        Stefan

RE: [found the culprit]

[Drew Adams]

> The question is not "what do we do when we receive an uncompressed tar
> file", but rather "what do we do when we have a compressed tar file"
> and "what do we do when the user requests to compress a directory".

`Z' should do what it's long done.

But if you want to give it a special behavior for
directories, I have no objection.  I already said
that the particular command can have behavior that
treats exceptions exceptionally.  The exception
is for directories - we should not change the whole
`Z' command for all tar and tar.gz just because we
want to do something special in the case of directories.

As for the behavior that you want - the new `Z'
behavior: just define it as a new, different command.
Give it another key, if you think that's needed.

I don't see why the general behavior of `Z' should
be changed for tar/tar.gz/.tgz, just because of the
desire to do something better for directories.

> in my experience ".tar.gz" is itself considered as an
> archive format rather
> than "a compressed file which contains an archive"

Fair enough.  But that's not the only way it's
considered, I think.  It is still possible, at
least outside Dired, to uncompress without extracting,
right?

> in the sense that in the vast majority of cases people
> take a directory and pack it up into a .tar.gz "tarball"
> or take a ".tar.gz" and unpack it into a directory tree:
> the cases where the .tar intermediate step is used
> explicitly are much less frequent.

Yes, though an exception, the directory case is
common. ;-)

It's an exception, in that its only one thing you can
tar up and compress.  But you're right that it is
very common.

Maybe we should have a separate command for it?

> > The question is whether `Z' should support tar files.
> 
> No.  It does and has done so for a long time and there's
> no suggestion to make it stop supporting it.
> 
> And indeed Dired's `Z` has been compressing directories to tar.gz and
> uncompressing tar.gz to directories (rather than to tar files) for many
> years now.

So what's new is that it now does the same for
non-directories?  If so, why is that good/needed?

Maybe I'm misunderstanding what this is all about.
If so, I'm sorry for all the noise.

Re: [found the culprit]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 14 Nov 2018 13:20:00 -0500
> 
> And indeed Dired's `Z` has been compressing directories to tar.gz and
> uncompressing tar.gz to directories (rather than to tar files) for many
> years now.

Well, for some value of "many": that feature was added 3 years ago, if
my Git-fu is strong enough.

Re: [found the culprit]

[Stefan Monnier]

>> And indeed Dired's `Z` has been compressing directories to tar.gz and
>> uncompressing tar.gz to directories (rather than to tar files) for many
>> years now.
>
> Well, for some value of "many": that feature was added 3 years ago, if
> my Git-fu is strong enough.

I thought it was added to Emacs-24, but indeed it only appeared in
Emacs-25.  So, yes, that doesn't qualify for "many".  "A few"?


        Stefan

Re: [found the culprit]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 14 Nov 2018 11:39:56 -0500
> 
> > I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
> > file, should not by default unpack the archive.  We could have a
> > special prefix arg to request that, and by default we should just
> > uncompress the file.  But that's a different issue.
> 
> FWIW, I consider ".tar.gz" (or "tar.lz", ...) as the archive format
> (rather than as a combination of tar and compression): since the tar
> format does not support random access anyway there's very little benefit
> to having it uncompressed (unless the content can't be compressed
> e.g. because it's already compressed).

But then 'Z' shouldn't invoke unpacking, because it is documented as
"uncompress" operation.  By unpacking the archive we second-guess the
users, and decide for them that they meant to uncompress a directory
(or several directories), which is just one of two possible
interpretations.

Maybe the solution is to define a new command, "archive", which could
work on one or more files or directories for compression, and remove
the directory compression from what 'Z' does.  Then the inverse for
the new command would both decompress and unpack the archive.

Re: [found the culprit]

[Stefan Monnier]

>> > I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
>> > file, should not by default unpack the archive.  We could have a
>> > special prefix arg to request that, and by default we should just
>> > uncompress the file.  But that's a different issue.
>> 
>> FWIW, I consider ".tar.gz" (or "tar.lz", ...) as the archive format
>> (rather than as a combination of tar and compression): since the tar
>> format does not support random access anyway there's very little benefit
>> to having it uncompressed (unless the content can't be compressed
>> e.g. because it's already compressed).
>
> But then 'Z' shouldn't invoke unpacking, because it is documented as
> "uncompress" operation.

But if you consider ".tar.gz" in the same way as ".zip" (i.e. the
compression is indivisible from the archiving), then does that mean you
think it should signal an error when asked to uncompress such a file?

AFAICT Emacs has unpacked .tar.gz when asked to uncompress them for many
years and noone has complained about it so far.  I think it's the most
natural thing to do.  The only recent change in this regard is to adjust
the behavior on .tgz so it works like .tar.gz (the old behavior was
really odd to me: the name ".tgz" even more strongly hints at the
desire to treat archiving and compression as indivisible, so it was
very strange for Emacs to only uncompress rather than unpack it when the
same operation .tar.gz unpacked it).


        Stefan

Re: [found the culprit]

[jpff]

On Wed, 14 Nov 2018, Stefan Monnier wrote:

>
> AFAICT Emacs has unpacked .tar.gz when asked to uncompress them for many
> years and noone has complained about it so far.

This discussion has exlained so many problems I have been having with Z on 
tar files.  No i did not complain but thought i must have mistyped 
something or put a thimbpalm on the bl**dy track pad, and so I avoid 
usung emacs for some things I used to do.

==John ff

Re: [found the culprit]

[Van L]

>> AFAICT Emacs has unpacked .tar.gz when asked to uncompress them for many
>> years and noone has complained about it so far.
> 
> This discussion has exlained so many problems I have been having with Z on tar files.  No i did not complain but thought i must have mistyped something or put a thimbpalm on the bl**dy track pad, and so I avoid usung emacs for some things I used to do.

I don’t use the feature; but, if I am going to, in a situation where I know I won’t run out of storage space, I’d want to save on time and be quick and default to the one step to tar and back. I’d only want to consider the two step to tar.gz and back at 80% of storage consumed or I intend to send a sizeable copy across the net to save time.

Re: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
  > file, should not by default unpack the archive.

I agree.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [emacs -q versus empty .emacs file] (was: tgz extension and dired-do-compress)

[Alan Mackenzie]

Hello, Uwe.

On Wed, Nov 14, 2018 at 13:07:37 +0100, Uwe Brauer wrote:
> >>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


>    > I don't know, because it works for me.  Did you try in "emacs -Q"?


> I also  tried out emacs -q and it works as expected, but when I start
> emacs 

Please don't confuse "emacs -Q" with "emacs -q" - they're not the same.

> with a .emacs file which is empty the behavior of dired changes, so
> something is loaded but what?

> According to man emacs: emacs -q just does not load the init file

> So why does not emacs -q and an empty .emacs file show the same behavior?

With "-q", you're loading site-start.el, should it exist, but not your
.emacs.

With "-Q", you don't even load site-start.el.

Hope that helps!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [emacs -q versus empty .emacs file]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

   > Hello, Uwe.
   > On Wed, Nov 14, 2018 at 13:07:37 +0100, Uwe Brauer wrote:
   >> >>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   >> > I don't know, because it works for me.  Did you try in "emacs -Q"?


   >> I also  tried out emacs -q and it works as expected, but when I start
   >> emacs 

   > Please don't confuse "emacs -Q" with "emacs -q" - they're not the same.


I know. Sorry for any misleading comments.


   > Hope that helps!

The point is, as I wrote in a later message:
it is the version of emacs which makes the difference

So 

emacs25 -q (or -Q) 

shows the behavior Eli was mentioning and which I
was expecting

However 
emacs27 -q (or -Q)

Shows the new behavior 

(Z in dired mode does not uncompress tgz to tar, but extract it
contents!)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

RE: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Drew Adams]

> It seems I misunderstood your original report: you wanted Z on a .tgz
> file to only uncompress it?  That indeed has been changed in Emacs 26,
> for consistency with a .tar.gz file.  I don't think it's a good idea
> to have the previous subtle difference back.
> 
> I do think that Z on a compressed Tar archive, be it a .tar.gz or .tgz
> file, should not by default unpack the archive.  We could have a
> special prefix arg to request that, and by default we should just
> uncompress the file.  But that's a different issue.

`Z' should be its own inverse.  And there definitely
needs to be a way to compress a tar file and get it
back again from the compressed file.  Unpacking is
something else.  If `Z' compresses then if used again it
should only uncompress, returning what you started with.

It's fine to have another key that unpacks a tar, or
even another key that both uncompresses and unpacks.

Is it hard to hit two keys to uncompress + unpack?
I'm a bit surprised to see that this change was made,
after decades of the pre-26 behavior.  Was something
big gained by it?

BTW, I don't see this change called out in NEWS for
Emacs 26.  Is it there and I just missed it?

Personally, I'd prefer that a choice to both uncompress
and unpack _not_ be made via a "special prefix arg" for
`Z'.  If you can use a prefix arg with `Z' then you can
hit two keys to get the uncompress + unpack behavior.

My main reason for preferring that the prefix arg not
be co-opted for this is that in my Dired+ code I have
long co-opted it ( ;-) ) to use the following special
prefix args (and the same are used for _lots_ of Dired
commands):

 Compress or uncompress marked (or next prefix argument) files.
 A prefix argument ARG specifies files to use instead of marked.
  An integer means use the next ARG files (previous -ARG, if < 0).
  `C-u': Use the current file (whether or not any are marked).
  `C-u C-u': Use all files in Dired, except directories.
  `C-u C-u C-u': Use all files and directories, except `.' and `..'.
  `C-u C-u C-u C-u': Use all files and all directories.

What's added are the multiple `C-u' prefixes.

Vanilla Dired could benefit from the same behavior, for
dired-do-* commands generally.  To provide this behavior
I redefined macro `dired-map-over-marks' slightly:

 If ARG is a cons with element 16, 64, or 256, corresponding to
   'C-u C-u', 'C-u C-u C-u', or 'C-u C-u C-u C-u', then use all files
   in the Dired buffer, where:
     16 includes NO directories (including '.' and '..')
     64 includes directories EXCEPT '.' and '..'
    256 includes ALL directories (including '.' and '..')
 If ARG is otherwise non-nil, use the current file.

Re: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Eli Zaretskii]

> Date: Wed, 14 Nov 2018 08:17:39 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> `Z' should be its own inverse.

It is.  But there's a problem with "compressing" directories: Emacs
26.1 introduced an ambiguity, because 'Z' on a directory produces a
.tar.gz archive out of its files, but 'Z' on a .tar.gz file can either
uncompress to produce a .tar file or unpack all the files into a
directory.

> It's fine to have another key that unpacks a tar, or
> even another key that both uncompresses and unpacks.

Then someone will complain that 'Z' on a directory is not its own
inverse.

> BTW, I don't see this change called out in NEWS for
> Emacs 26.  Is it there and I just missed it?

It wasn't announced, and the manual wasn't updated to say what 'Z'
does in a directory.  Shame on us.

>  Compress or uncompress marked (or next prefix argument) files.
>  A prefix argument ARG specifies files to use instead of marked.
>   An integer means use the next ARG files (previous -ARG, if < 0).
>   `C-u': Use the current file (whether or not any are marked).
>   `C-u C-u': Use all files in Dired, except directories.
>   `C-u C-u C-u': Use all files and directories, except `.' and `..'.
>   `C-u C-u C-u C-u': Use all files and all directories.

Is "C-u 0' available?

Re: [found the culprit]

[Stefan Monnier]

>>  Compress or uncompress marked (or next prefix argument) files.
>>  A prefix argument ARG specifies files to use instead of marked.
>>   An integer means use the next ARG files (previous -ARG, if < 0).
>>   `C-u': Use the current file (whether or not any are marked).
>>   `C-u C-u': Use all files in Dired, except directories.
>>   `C-u C-u C-u': Use all files and directories, except `.' and `..'.
>>   `C-u C-u C-u C-u': Use all files and all directories.
>
> Is "C-u 0' available?

I don't think we should base our decision on what some external package
happened to choose.  Especially since the above C-u usage does not
follow Emacs's use of C-u.


        Stefan

RE: [found the culprit]

[Drew Adams]

> >>  Compress or uncompress marked (or next prefix argument) files.
> >>  A prefix argument ARG specifies files to use instead of marked.
> >>   An integer means use the next ARG files (previous -ARG, if < 0).
> >>   `C-u': Use the current file (whether or not any are marked).
> >>   `C-u C-u': Use all files in Dired, except directories.
> >>   `C-u C-u C-u': Use all files and directories, except `.' and `..'.
> >>   `C-u C-u C-u C-u': Use all files and all directories.
> >
> > Is "C-u 0' available?
> 
> I don't think we should base our decision on what some external package
> happened to choose.  Especially since the above C-u usage does not
> follow Emacs's use of C-u.

1. I didn't say you should base your decision on what Dired+
uses.  I just mentioned what it uses, and has used for a
long time.  And it's a general scheme, applied to `dired-do-*'
commands generally.  The conflict is not a minor one, e.g.,
affecting just `Z'.

A better idea is for vanilla Emacs to adopt that general
scheme.  It's a good scheme - I didn't just "happen to
choose" it.  And it fits with the existing vanilla behavior,
both wrt numeric arg and plain C-u.  The only divergence is
the addition of behaviors for multiple C-u, which most users
will use much less commonly.  (Well, actually, I find I use
multiple C-u more than I use numeric.)

2. How does the above C-u usage "not follow Emacs's use of C-u"?

3. `Z' is a `dired-do-*' command.  Its prefix arg behavior
should, other things being equal, follow the pattern of
the other `dired-do-*' commands.

However, the behavior of `Z' itself (`dired-do-compress')
can be whatever you want, including treating directories
specially.

Re: [found the culprit]

[Stefan Monnier]

> I just mentioned what it uses, and has used for a
> long time.  And it's a general scheme, applied to `dired-do-*'
> commands generally.  The conflict is not a minor one, e.g.,
> affecting just `Z'.

FWIW, I don't think it's a good scheme.  Better would have
more mark-management commands that you can then combine with any
dired command without having to fight with conflicting uses of C-u.
E.g. commands to "push" and "pop" the current set of marked files,
and a command that you can iterate like your C-u which will first mark
the current file, then the files in the current directory, then ...
A nice advantage to C-u is that these would give you visual feedback
about which files are selected.

> 2. How does the above C-u usage "not follow Emacs's use of C-u"?

Emacs usually does not use multiple C-u and also tries to avoid
distinguishing between "just C-u" and "a numeric argument".  There are
exceptions to both of those "rules", and I'm to blame for some of those
exceptions, but I think this case is not a good candidate for an
exception because there are too many "sets of files" that the user might
like to specify, so we'll be better served by providing this separately
than trying to cleverly cram some common cases into the narrow C-u.


        Stefan

RE: [found the culprit]

[Drew Adams]

> > I just mentioned what it uses, and has used for a
> > long time.  And it's a general scheme, applied to `dired-do-*'
> > commands generally.  The conflict is not a minor one, e.g.,
> > affecting just `Z'.
> 
> FWIW, I don't think it's a good scheme.

And I (who use it) think it's a good scheme. ;-)

> Better would have more mark-management commands that
> you can then combine with any dired command

We already have great mark-management commands,
including the ability to define multiple sets of
files using different marks (not-known-well-enough
key `* c').

> without having to fight with conflicting uses of C-u.

There's no fight with conflicting uses of `C-u'.
I already explained that it fits well with the
existing prefix arg use for `dired-do-*'.  It
only interprets multiple plain `C-u' specially.

Do you really think that someone needs to rely on
being able to use `C-u C-u C-u' to specify the
current file, instead of just `C-u'?  That makes
no sense to me.

> E.g. commands to "push" and "pop" the current set of marked files,

See `* c'.  I'm guessing that that's the kind of
thing you're aiming for.  But it's more general
than just a stack: direct access to anywhere in
the "stack", to change any set of markings to
another, anytime.

> and a command that you can iterate like your C-u which will first mark
> the current file, then the files in the current directory, then ...
> A nice advantage to C-u is that these would give you visual feedback
> about which files are selected.

So you in fact propose a completely different
use of `C-u' from what Emacs has always used
for `dired-do-*'.  Talk about fighting with
conflicting uses of `C-u'!  That retains
nothing of what we have now wrt a prefix arg.

Anyway, if that's what you want for vanilla
Emacs, go for it.

> > 2. How does the above C-u usage "not follow
> >    Emacs's use of C-u"?
> 
> Emacs usually does not use multiple C-u

"Usually does not use" does not mean that using
multiple `C-u' does not follow Emacs's use of
`C-u'.  Not in the sense of some prescribed use,
in any case.

Emacs usually does not distinguish plain `C-u' from
numeric use.  It doesn't usually do so because
usually - for most commands - there is only one
prefix-arg behavior.  (Actually zero, for most.)

It would be silly to suppose that there were some
unwritten "rule" that "Emacs use" is to not use
prefix args, just because most commands don't use
a prefix arg.  Same thing for a command recognizing
different kinds of prefix arg: don't confuse
frequency of use with prescription of whether or
not to use.

> and also tries to avoid
> distinguishing between "just C-u" and "a numeric
> argument".

I see no indication that Emacs avoids that.  Just
because most commands offer only one prefix-arg
behavior, and so there is no need to distinguish,
that doesn't mean that there is an unwritten
convention to avoid such distinction.

And if there were such a convention (preferably
written), I'd oppose it - but that's just me.
I think the existence of the prefix-arg "feature"
is a good thing.  If it didn't exist it would be
good to invent it.  Same thing for the various
different kinds of prefix arg - I'm thankful for
them.  (I sometimes even wish there were more.)

> There are exceptions to both of those "rules",

I don't agree that there any such rules.  There
are just commands that do not (yet) offer more
than one behavior.  Lots of them.  So what?

And I don't think Emacs should have such "rules".
On the contrary, I think there are many commands
that could benefit from adding alternative
behaviors by way of a prefix arg.  As opposed,
for example, to adding lots of additional key
bindings.

Give me one command and key binding for a related
set of operations, some of which I use much less
often, rather than N commands, bound to N keys,
with N doc strings that are similar but subtly
different ... for the same set of behaviors as
that one key with prefix-arg possibilities.

Saves keys, puts less-used behaviors on slightly
more cumbersome bindings (you have to use a prefix
arg for them), groups related behaviors on similar
keys, facilitates discoverability and recall...

> and I'm to blame for some of those
> exceptions, but I think this case is not a good candidate for an
> exception because there are too many "sets of files" that the user
> might like to specify, so we'll be better served by providing this separately
> than trying to cleverly cram some common cases into the narrow C-u.

It's OK to disagree. ;-)  If I thought there were
other, more common sets of files that users typically
want to act on with Dired then I'd no doubt use
those sets instead.

These are the most common sets that I, at least, want
to act on - they are all ways of acting on "all" files.

Such cases are about as important to me as the case of
wanting to act on just the current-line file.  Just like
that special case (yes, yet another special prefix-arg
case that is built into Emacs), it's about being able
to act on files while ignoring (and so not needing to
change and restore) the current markings.

I'll add this, which you might or might not agree might
be relevant: you've said in the past that you don't
even use Dired, or at least that you don't use it much.

(That doesn't in any way invalidate your arguments,
either about acting on files in Dired or about the
prefix arg in general.)

Re: [found the culprit]

[Davis Herring]

> `Z' should be its own inverse.

This is a reasonable principle, but there is a reason to deviate from it 
here.  The uncompressed tar format is so rarely used (partly because of 
the lack of actual tape drives, and partly because of change in the 
relative cost of CPU cycles and storage space) that having a convenient 
key to get _to_ it is unimportant.  The unpacked and compressed-tar 
states, however, are both deserving of such a key.  Therefore, whatever 
behavior (unpack or compress) we choose to apply to a .tar will not be 
inverted by a second Z -- because the initial state is presumed to be 
undesirable.

For example, on some machines I use, "git archive" cannot produce 
compressed archives.  Having Z compress its raw .tar output would be, to 
me, a useful way of working around that limitation.  But other users 
might prefer that Z unpack a .tar -- and then repack the resulting 
(hopefully single) directory into a .tgz.

Could Z query for which behavior to use in this (rare) case?  That would 
provide an intuitive reason why a second Z would not necessarily reverse 
the process.  (The query could even say so explicitly if it helped.)

> Is it hard to hit two keys to uncompress + unpack?

Yes, because the operations are frequently slow and you wouldn't want to 
have to input a second key after a delay (or blindly).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

RE: [found the culprit]

[Drew Adams]

> > `Z' should be its own inverse.
> 
> This is a reasonable principle, but there is a reason to deviate from
> it here.  The uncompressed tar format is so rarely used (partly because of
> the lack of actual tape drives, and partly because of change in the
> relative cost of CPU cycles and storage space) that having a convenient
> key to get _to_ it is unimportant.  The unpacked and compressed-tar
> states, however, are both deserving of such a key.  Therefore, whatever
> behavior (unpack or compress) we choose to apply to a .tar will not be
> inverted by a second Z -- because the initial state is presumed to be
> undesirable.
> 
> For example, on some machines I use, "git archive" cannot produce
> compressed archives.  Having Z compress its raw .tar output would be,
> to me, a useful way of working around that limitation.  But other users
> might prefer that Z unpack a .tar -- and then repack the resulting
> (hopefully single) directory into a .tgz.
> 
> Could Z query for which behavior to use in this (rare) case?  That
> would provide an intuitive reason why a second Z would not necessarily
> reverse the process.  (The query could even say so explicitly if it helped.)

It sounds like you are arguing for `Z' to in fact be
its own inverse, and in the case of tar.gz and .tgz
to consider, as Stefan suggested, that that's the
inverse state from extracted (un(tarred+compressed)).

And you are saying (again, like Stefan), that the
plain tar case is now an outlier, so it can be
ignored, at least by `Z'.  That's OK by me.  Maybe
we should have a (new) separate command that deals
with plain tars (creation and production from tar.gz),
and perhaps that command needs no key.

I don't have a problem with that, if that's the state
of the real use cases now.

A zip archive, like a tar, need not contain a directory.
It sounds like both could be handled the same way.
If that leaves some tar cases out in the cold then they
can perhaps be warmed up with a new command.

And we can maybe get updated doc and a NEWS entry... ;-)

Re: [found the culprit]

[Mike Kupfer]

Davis Herring wrote:

> > `Z' should be its own inverse.
> 
> This is a reasonable principle, but there is a reason to deviate from
> it here.  The uncompressed tar format is so rarely used (partly
> because of the lack of actual tape drives, and partly because of
> change in the relative cost of CPU cycles and storage space) that
> having a convenient key to get _to_ it is unimportant.

Perhaps to you, or perhaps even to most Emacs users.  Me, I'd like to
get the .tar file back.  It doesn't need to be the default behavior--I'd
be happy if there were a user option that would let me control whether
the file is unpacked or not.

There are a couple problems with the current behavior that are mentioned
in #25611, but which I haven't seen covered in the current discussion.

1. The prompt doesn't say anything about unpacking.

2. It's possible to silently overwrite user files, both because of (1)
and because the code makes assumptions about the contents of the tar
file.

3. There is a potential exploit due to (2).

I don't list these as arguments against the current behavior, just as
things that should be fixed.

mike

Re: [found the culprit]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I agree with you about what Z should do, but there is an additional
reason.

The meaning of Z is to compress or uncompress.  Extracting an archive is
a different operation; it is semantically incoherent for Z to extract
an archive.

If we want a Dired command to extract archives, we should add one.
It can handle .tgz files as well as .tar files and other archive types.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [found the culprit]

[Clément Pit-Claudel]

On 15/11/2018 19.55, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I agree with you about what Z should do, but there is an additional
> reason.
> 
> The meaning of Z is to compress or uncompress.  Extracting an archive is
> a different operation; it is semantically incoherent for Z to extract
> an archive.
> 
> If we want a Dired command to extract archives, we should add one.
> It can handle .tgz files as well as .tar files and other archive types.

I think this distinction (unpacking vs decompressing) is too subtle.  What should we do on formats that support both, like zip?  That is, should Z on a zip archive just change its compression mode to store, without extracting the files?

Maybe I'm misunderstanding the proposal?

Clément.

Re: [found the culprit]

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 15 Nov 2018 21:24:43 -0500
> 
> > The meaning of Z is to compress or uncompress.  Extracting an archive is
> > a different operation; it is semantically incoherent for Z to extract
> > an archive.
> > 
> > If we want a Dired command to extract archives, we should add one.
> > It can handle .tgz files as well as .tar files and other archive types.
> 
> I think this distinction (unpacking vs decompressing) is too subtle.  What should we do on formats that support both, like zip?  That is, should Z on a zip archive just change its compression mode to store, without extracting the files?

Where there's only one meaning of Z, there's no problem.  Hardly
anyone would want Z on a zip archive to change the compression method;
that's not what Z is about: it compresses or decompresses, and
decompressing a zip archive _means_ unpacking it.

But with .tar.gz files, decompressing and unpacking are two separate
actions, so there's an ambiguity what Z might mean.  And IMO (and also
in Richard's, AFAIU), the ambiguity should be resolved in the least
surprising way.  Having all the files from an archive extracted
without my explicit permission is a surprise, might even be unpleasant
surprise.

Re: [found the culprit]

[Stefan Monnier]

> But with .tar.gz files, decompressing and unpacking are two separate
> actions, so there's an ambiguity what Z might mean.  And IMO (and also
> in Richard's, AFAIU), the ambiguity should be resolved in the least
> surprising way.  Having all the files from an archive extracted
> without my explicit permission is a surprise, might even be unpleasant
> surprise.

Could we have a config flag for that, then?  un/packing tar.gz is
the behavior I expect from `Z`, whereas uncompressing tar.gz and
signaling an error on directories is completely useless to me.


        Stefan

Re: [found the culprit]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Where there's only one meaning of Z, there's no problem.  Hardly
  > anyone would want Z on a zip archive to change the compression method;
  > that's not what Z is about: it compresses or decompresses, and
  > decompressing a zip archive _means_ unpacking it.

It does not literally make sense to "decompress" an archive.  Any kind
of archive.  That stretches the meaning of "decompress".

Such stretching might be ok, if it led to no confusion or conflict.
However, what we see is that it does lead to confusion.  So Z should
not unpack archives -- not even zip archives.

Instead, we should have a different letter for unpacking archives.
I suggest moving dired-do-find-regexp to F
ad defining A to unpacking an archive.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: [found the culprit]

[Drew Adams]

> > I agree with you about what Z should do, but there is an additional
> > reason.
> >
> > The meaning of Z is to compress or uncompress.  Extracting an archive is
> > a different operation; it is semantically incoherent for Z to extract
> > an archive.
> >
> > If we want a Dired command to extract archives, we should add one.
> > It can handle .tgz files as well as .tar files and other archive types.
> 
> I think this distinction (unpacking vs decompressing) is too subtle.  What
> should we do on formats that support both, like zip?  That is, should Z on a
> zip archive just change its compression mode to store, without extracting the
> files?

Does zip "support both"?  I think that's the
difference: it does not do _each_ of those
things; it has only one action, which combines
both things.

I can't speak for Richard, but my response to
your question would be that if, as in the case
of zip, there is _no distinction_, then we need
not distinguish.  We can just do what we do now:
perform that atomic action.

Call it compress/uncompress or pack/unpack or
compress+pack/unpack+uncompress, or call it
anything you like, for zip.  There's nothing
wrong with letting `Z' perform that one action
and its inverse, alternately.

The problem for tar.gz and .tgz is that there
_is_ a distinction (regardless of how uncommonly
people make use of it): plain tar exists: packed
and uncompressed.

As I said, and as Eli reiterated: let's have a
separate command.  As I said, I am even OK with
letting the presumably more common use case get
the `Z' binding (though that's not what I'd
prefer because of backward compatibility).

But what I don't think is a good idea is to
remove support for uncompressing tar.gz/.tgz
without unpacking.  If necessary and if everyone
wants the combination operation to get the `Z'
binding, then put the presumably less-used
single operation on a different command.

Re: [found the culprit]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I can't speak for Richard, but my response to
  > your question would be that if, as in the case
  > of zip, there is _no distinction_, then we need
  > not distinguish.  We can just do what we do now:
  > perform that atomic action.

Uncompression produces one file which corresponds to the original
file.  You can type Z again and recompress it.

Unpacking one archive file can result in multiple files.
It is misleading semantically to identify this with uncompression.

A Dired command to unpack an archive might lead to confusing results,
because the unpacked files might be outside the directory you are
operating on.

I do not see how to support packing an archive in Dired, because I do
not see a clean and simple way to specify which files to put in it.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [found the culprit]

[Yuri Khan]

On Sat, Nov 17, 2018 at 6:02 AM Richard Stallman <rms@gnu.org> wrote:

> I do not see how to support packing an archive in Dired, because I do
> not see a clean and simple way to specify which files to put in it.

In the majority of the actual use cases, one wants to pack one or more
files or subdirectories located in the current directory, with
directories packed recursively with all their contents. The natural UI
to that is “optionally mark everything you want packed, type a key,
enter the archive name”. If no items are marked, pack the file or
directory at point.

A more involved scenario is that one has a tree where some files
should and others should not go into the archive. Any other file
manager would be hard-pressed to support this efficiently, but Dired
has the ‘dired-maybe-insert-subdir’ feature (bound to ‘i’ by default)
that expands a subdirectory in the same buffer. So one could expand as
many subdirectories as are necessary to make the selection, set marks,
and invoke the archiving command, which would pack the files keeping
the relative directory structure.

An even more involved case is where one has a tree and wants to pack
its files into a different directory structure. Most command-line
archivers do not even provide for that case, so Dired needn’t either.

Re: [found the culprit]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In the majority of the actual use cases, one wants to pack one or more
  > files or subdirectories located in the current directory, with
  > directories packed recursively with all their contents. The natural UI
  > to that is “optionally mark everything you want packed, type a key,
  > enter the archive name”. If no items are marked, pack the file or
  > directory at point.

This interface would make sense for the new A command I've proposed.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [found the culprit]

[Clément Pit-Claudel]

On 16/11/2018 11.17, Drew Adams wrote:
> Does zip "support both"?  I think that's the
> difference: it does not do _each_ of those
> things; it has only one action, which combines
> both things.

No, it does support both (you can create a zip file in "store" mode, with no compression applied)

Re: [found the culprit]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think this distinction (unpacking vs decompressing) is too subtle.

They don't seem even similar to me.  tar xf  and  gunzip  are not
at all similar in spirit.

  > That is, should Z on a zip archive just change its compression
  > mode to store, without extracting the files?

If there is such a thing as compression mode in a zip archive (I don't
know), that would make sense.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [found the culprit]

[Yuri Khan]

On Sat, Nov 17, 2018 at 6:02 AM Richard Stallman <rms@gnu.org> wrote:

>   > That is, should Z on a zip archive just change its compression
>   > mode to store, without extracting the files?
>
> If there is such a thing as compression mode in a zip archive (I don't
> know), that would make sense.

There is, but it doesn’t.

A .tar.gz archive is (most of the time) a single compressed stream of
a multi-file container.

On the contrary, a zip archive is a container of multiple compressed
file streams. So, in a zip archive, each contained file can be
compressed by a different algorithm. It does not make sense to only
give the user a way to change compression for all files in a zip at
once.

Re: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Yuri Khan]

On Wed, Nov 14, 2018 at 11:18 PM Drew Adams <drew.adams@oracle.com> wrote:

> Is it hard to hit two keys to uncompress + unpack?
> I'm a bit surprised to see that this change was made,
> after decades of the pre-26 behavior.  Was something
> big gained by it?

The big gain from uncompressing and unpacking in one go is that you
can skip storing the .tar, and you get to keep the original .tar.gz.
This is both time- and space-efficient.

Re: [found the culprit]

[Andreas Schwab]

On Nov 15 2018, Yuri Khan <yurivkhan@gmail.com> wrote:

> The big gain from uncompressing and unpacking in one go is that you
> can skip storing the .tar, and you get to keep the original .tar.gz.
> This is both time- and space-efficient.

But that should be a separate command, since Z is only about
uncompressing.  If you want to recompress the file, unpacking the
archive is silly.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [found the culprit]

[Yuri Khan]

On Thu, Nov 15, 2018 at 4:46 PM Andreas Schwab <schwab@suse.de> wrote:

> > The big gain from uncompressing and unpacking in one go is that you
> > can skip storing the .tar, and you get to keep the original .tar.gz.
> > This is both time- and space-efficient.
>
> But that should be a separate command, since Z is only about
> uncompressing.  If you want to recompress the file, unpacking the
> archive is silly.

In the specific use case of recompressing (possibly to a different
compression algorithm), I agree.

RE: [found the culprit] (was: [emacs -q versus empty .emacs file])

[Drew Adams]

> > `Z' should be its own inverse.
> 
> It is.  But there's a problem with "compressing" directories: Emacs
> 26.1 introduced an ambiguity, because 'Z' on a directory produces a
> .tar.gz archive out of its files,

So a directory is a special case, if no one will have
a tar file for a directory (so they only have tar.gz's).

In that case a directory should be the same special case
for inversing.  We should not, I think change the general
case for inversing compression just because in the case
of a directory compression means something different.

> but 'Z' on a .tar.gz file can either
> uncompress to produce a .tar file or unpack all the files
> into a directory.
> 
> > It's fine to have another key that unpacks a tar, or
> > even another key that both uncompresses and unpacks.
> 
> Then someone will complain that 'Z' on a directory is not
> its own inverse.

See above.  Either a directory is a special case or it's
not.  It sounds like it is.

> > BTW, I don't see this change called out in NEWS for
> > Emacs 26.  Is it there and I just missed it?
> 
> It wasn't announced, and the manual wasn't updated to say what 'Z'
> does in a directory.  Shame on us.

;-)

> >  Compress or uncompress marked (or next prefix argument) files.
> >  A prefix argument ARG specifies files to use instead of marked.
> >   An integer means use the next ARG files (previous -ARG, if < 0).
> >   `C-u': Use the current file (whether or not any are marked).
> >   `C-u C-u': Use all files in Dired, except directories.
> >   `C-u C-u C-u': Use all files and directories, except `.' and `..'.
> >   `C-u C-u C-u C-u': Use all files and all directories.
> 
> Is "C-u 0' available?

Depends on what you mean by available.

`C-u 0' for `dired-do-*' commands means act on the next zero
files. In the case of `Z' it (un)compresses no files.  Should
we leave it that way?  I think so.  You can invoke a `dired-do-*'
command from Lisp code, and you might have code that expects
zero to behave as it does now.

I also think it's good for `dired-do-*' commands to share
prefix-arg behavior, other things being equal.

Should a zero numeric prefix arg be redefined for `dired-do-*'
commands generally?  I don't think so, but that could be
something to consider.

But back to square one: Is a directory special, in that no
one will have a tar file for a directory - everyone will
have only a tgz or a tar.gz file?  If it is, then let `Z'
special-case directories.  Is that possible?  To decompress
a tar.gz it would try to decompress to a tar, but if the
result is a directory then the result is, well, a directory
and not a tar.