From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add shell-quasiquote. Date: Tue, 20 Oct 2015 19:28:56 +0200 Message-ID: <87mvvdih47.fsf@T420.taylan> References: <87si59wj42.fsf@T420.taylan> <878u6znii9.fsf@T420.taylan> <836123gfh2.fsf@gnu.org> <87r3krm0t3.fsf@T420.taylan> <5624F66F.1030600@yandex.ru> <87io63lzkg.fsf@T420.taylan> <562508B7.3020202@yandex.ru> <876122n5v3.fsf@T420.taylan> <22053.50324.60123.654292@turnbull.sk.tsukuba.ac.jp> <87d1waknl1.fsf@T420.taylan> <87oafugeia.fsf@fencepost.gnu.org> <87wpuij5vm.fsf@T420.taylan> <87d1w9hql5.fsf@fencepost.gnu.org> <87oaftkjhg.fsf@T420.taylan> <83fv15ft07.fsf@gnu.org> <874mhljyd7.fsf@T420.taylan> <838u6xfppw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445362162 15485 80.91.229.3 (20 Oct 2015 17:29:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 17:29:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 19:29:21 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zoaiq-0000aY-6R for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 19:29:16 +0200 Original-Received: from localhost ([::1]:47272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoaip-0007jU-JA for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 13:29:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zoaia-0007ev-DN for emacs-devel@gnu.org; Tue, 20 Oct 2015 13:29:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoaiZ-0005v3-3H for emacs-devel@gnu.org; Tue, 20 Oct 2015 13:29:00 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:37389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoaiY-0005uu-QZ; Tue, 20 Oct 2015 13:28:59 -0400 Original-Received: by wicfv8 with SMTP id fv8so39674789wic.0; Tue, 20 Oct 2015 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=p5ySzFOkYup7WM0vwXvH4xcQSJ0Jv82J48y1QuYeLoY=; b=ofRckQxlOt6a1vlXeAOqj4HitCuM+VsrKtREWBwuTpWjrZIIoOx3/QatF7nz904/Ph t8AVieGw0UWtF2/cJXF0hlD0SZn0hblX+9BJhKUGePNQYTlCOAYQVje3QILpFxyuxb6L m1xGSnbzskGdFUznmXdWknQsGXAEfprnUU9V9dbVVn7EMr6tTKePrJbAZqVpwgr97W1W 2KaL/LnurmmT9Pih8ZSKQOX1hmONZNuCHhzc6m/nZVyKsVlkwtoeynXeuuQSBTHnNLWg aMF6FxiGyY2UtKqhBwNiy71vgibAufjrVkIMnXJ/zqhzSOuaMgFcqA8cSgWFE3+28Unw Lccw== X-Received: by 10.180.187.141 with SMTP id fs13mr30668513wic.13.1445362138228; Tue, 20 Oct 2015 10:28:58 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id he3sm5072564wjc.48.2015.10.20.10.28.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 10:28:57 -0700 (PDT) In-Reply-To: <838u6xfppw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 20 Oct 2015 19:51:23 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:192209 Archived-At: Eli Zaretskii writes: >> From: taylanbayirli@gmail.com (Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer) >> Cc: emacs-devel@gnu.org >> Date: Tue, 20 Oct 2015 18:31:00 +0200 >>=20 >> > This is not about non-Posix shells (although that aspect did start >> > this thread). This is about using project-wide APIs for certain >> > standard jobs. That should have been a no-brainer, because it makes >> > no sense to have several functions doing the same job in subtly >> > different ways. >> > >> > So you were politely requested to call that function for quoting shell >> > arguments in your package. Doing that is the only thing that stands >> > in the way of accepting your package on ELPA. AFAIK, there were no >> > other comments. >> > >> > If you think shell-quote-argument should be changed, feel free to >> > submit a patch proposal to that effect, and state there your reasons >> > for the changes. If they are accepted, all Lisp programs in Emacs >> > that need to quote command arguments will work that way, and everybody >> > will win by having a better Emacs. >>=20 >> I've already provided an extensive explanation of the problem with >> shell-quote-argument, what the solution to that problem is, and provided >> a patch to apply that solution. >>=20 >> The patch was turned down. (By you.) > > That was about the documentation. I understood, perhaps incorrectly, > that you also thought the code of the function needed some changes. > At least your alternative implementation quotes slightly differently, > e.g. it quotes even if the string doesn't need any quoting (because it > includes only characters from the Posix portable set). It also quotes > 'like this', whereas shell-quote-argument uses backslashes. The bug report explicitly stated that the current implementation of shell-quote-argument passes the strictest criterion of correctness, and included a horrible stress-test script to demonstrate it, merely so I could justify my documentation patch. I think I'm trying to be much more cooperative than what you seem to believe. Please read my mails more carefully. I usually spend a lot of time on them to make them as clear and comprehensive as possible. Tell me if they get too "comprehensive," as in burdensome to read. >> > I cannot understand why you insist on tying your contribution with two >> > orthogonal issues: what and how should be quoted, and what should be >> > in the doc string. By doing this, you prevent acceptance of your >> > package, which IMO is a pity. >>=20 >> I don't know what you mean with "what and how should be quoted." > > See above; I hope now what I meant is clear. I see. No, I never said the difference between how shell-quote-argument and shqq--quote-string do things was significant. When I found out about the difference, I explicitly stated it was insignificant. >> The doc string can serve as a clear declaration of strict safety >> guarantees that will make the function appropriate for my use case. >> Until that's done, the function is not appropriate for my use case >> because it does not declare the guarantees necessary for my use case. > > Documentation cannot change what the code does. If the function will > be appropriate after changing its doc string, it is appropriate now. Documentation can change what associated code will do in the future. Sometimes, ensuring that code will remain appropriate in the future is very important, as in the cases I explained. >> In practical terms, as explained before, this means that someone editing >> the function in the future may insert bugs into it which, from what I've >> gathered from other posts in the thread, it indeed also had in the past. > > Documentation cannot prevent such incidents. However, we can make > this harder by adding tests for this function. There already are 3 > tests that use it, and we can add more if needed. Patches to add such > tests are welcome. Documentation can very well prevent such incidents, because in the case where the semantics of a function is wonky, as is the case in quoting strings for shell commands, it can be the documentation that makes the difference of how carefully future programmers think of what changes they're making to the code. Indeed, tests allow mechanically verifiable invariants, which is better. I might write such tests for shell-quote-argument in the future, but the lack of a bigger improvement does not justify the rejection of a smaller improvement. > The upshot is that it's a pity to hold off a package for reasons that > can and should be taken care of independently and orthogonally. > >> It has also not been verified whether it's void of such bugs for systems >> other than POSIX, which is why I left declaring that to you; my patches >> were only adding the declaration of safety for POSIX, which I've made >> very sure of and gladly take responsibility for. > > The test suite runs on all supported systems, including MS-Windows, > and the tests all succeed. This function is quite old, so any > problems with it should have been reported long ago. The issue with > an embedded newline doesn't exist on MS-Windows at all. For how long did the embedded newline problem remain in the POSIX variant, which is probably used by ten times as many people? >> All of these things I've already said before, multiple times, with >> different wording, every time as clearly as I could. > > I'm still hoping you will change your mind. I have not been given any reason to change my mind. Shoop da woop and we're talking about unit testing all of a sudden, and my actual points have once more been ignored. Congratulations! Taylan