From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [found the culprit] Date: Wed, 14 Nov 2018 21:59:09 +0200 Message-ID: <83sh0377n6.fsf@gnu.org> References: <875zx1xgiq.fsf@mat.ucm.es> <83lg5w9956.fsf@gnu.org> <87d0r76ewm.fsf_-_@mat.ucm.es> <87tvkjq2mh.fsf_-_@mat.ucm.es> <834lcj8y1f.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1542225539 17780 195.159.176.226 (14 Nov 2018 19:58:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2018 19:58:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 14 20:58:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gN1JP-0004Vw-06 for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 20:58:55 +0100 Original-Received: from localhost ([::1]:33954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN1LV-0005N8-G9 for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 15:01:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN1Ji-0004Ow-6y for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:59:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gN1Jf-0003vC-IQ for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:59:14 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN1Jf-0003v5-FR; Wed, 14 Nov 2018 14:59:11 -0500 Original-Received: from [176.228.60.248] (port=2813 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gN1Je-0004Cg-Uf; Wed, 14 Nov 2018 14:59:11 -0500 In-reply-to: (message from Stefan Monnier on Wed, 14 Nov 2018 11:39:56 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231148 Archived-At: > From: Stefan Monnier > 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.