From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [found the culprit] Date: Wed, 14 Nov 2018 13:21:00 -0800 (PST) Message-ID: References: <<875zx1xgiq.fsf@mat.ucm.es> <<83lg5w9956.fsf@gnu.org> <87d0r76ewm.fsf_-_@mat.ucm.es> <<87tvkjq2mh.fsf_-_@mat.ucm.es> <<834lcj8y1f.fsf@gnu.org> <40f8adf8-52a7-957b-db95-06df4d131b21@lanl.gov> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1542230359 11693 195.159.176.226 (14 Nov 2018 21:19:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2018 21:19:19 +0000 (UTC) Cc: Uwe Brauer , Eli Zaretskii , emacs-devel@gnu.org To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 14 22:19:14 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 1gN2Z7-0002tv-31 for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 22:19:13 +0100 Original-Received: from localhost ([::1]:34274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN2bD-0005lb-9I for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 16:21:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN2b7-0005lL-Dl for emacs-devel@gnu.org; Wed, 14 Nov 2018 16:21:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gN2b6-0003Eu-OC for emacs-devel@gnu.org; Wed, 14 Nov 2018 16:21:17 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:50518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gN2b0-0003Aa-2S; Wed, 14 Nov 2018 16:21:11 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAELEB2p145255; Wed, 14 Nov 2018 21:21:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=WuoqkTuAIpQHCh0a3wX3/Co7CynFYnqQr2veyFWZpIg=; b=R7Wnw4sQCbRy/S4hFnOTA2iRTbcw5TaquODjVZYlpeiwFsIYNHAoWNBBZWv8g1QzEGEe 1LAGKZBitBoBvbA1onSnVadd+NfalVoOpwqdfVIqY5QoidHUi/cv5tIDBwG4BvgrhJge 3LIui+Ssm8jBYffAs3NIIiz/7S4ATXP+rcdDNbgNSHSfQlrOOHyJxnUlyx9DMSki2vaQ ccVxE1Y3hTyfNxEBfSM8tB9l2qyI4chXpbwCqR+xy0icWDzGJpLqjsKN+gak6GfpYCOh 6h8aYtQP8Z5IIiqUb6DBcUQ7oube6P5l1YsPiQeTLOjeWz9LLBHMCIqq9EJQLN9cUqsZ SQ== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2nr7cs61ys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 21:21:08 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAELL2jX017468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 21:21:02 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAELL1Hn025087; Wed, 14 Nov 2018 21:21:02 GMT In-Reply-To: <40f8adf8-52a7-957b-db95-06df4d131b21@lanl.gov> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9077 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811140189 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 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:231153 Archived-At: > > `Z' should be its own inverse. >=20 > 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 o= f > 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. >=20 > 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. >=20 > 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 helpe= d.) 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... ;-)