From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Escaping quotes in docstrings, Was: A simple solution to "Upcoming loss of usability ..." Date: Sun, 2 Aug 2015 21:31:09 +0300 Message-ID: <55BE61ED.9010307@yandex.ru> References: <87egkzg7gb.fsf@gmail.com> <558C2E25.10303@cs.ucla.edu> <558C492E.9000705@yandex.ru> <558C7DE1.4060507@cs.ucla.edu> <558C82D2.1070408@yandex.ru> <558CBA7E.7060900@cs.ucla.edu> <558D403D.303@yandex.ru> <558EDD4C.4040002@cs.ucla.edu> <558EE315.3080107@yandex.ru> <558F10FA.409@cs.ucla.edu> <558F4804.1020406@yandex.ru> <559010D6.5090905@cs.ucla.edu> <559058AD.5060504@yandex.ru> <55908355.3080407@yandex.ru> <559356D2.4000103@cs.ucla.edu> <5594813A.3000705@yandex.ru> <5594E0DB.1080702@cs.ucla.edu> <559A1C54.5030405@cs.ucla.edu> <559A6F86.2080809@yandex.ru> <559AAD27.3000403@cs.ucla.edu> <559AFCC3.3070409@yandex.ru> <559B85BE.4070303@cs.ucla.edu> <559B902D.4000906@yandex.ru> <55BC22BB.4020002@cs.ucla.edu> <55BD34B2.5060001@yandex.ru> <55BDBF2C.10000@cs.ucla.edu> <55BE1255.3040401@yandex.ru> <55BE33AF.6080402@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438540297 16836 80.91.229.3 (2 Aug 2015 18:31:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Aug 2015 18:31:37 +0000 (UTC) To: Paul Eggert , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 02 20:31:36 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 1ZLy2p-0006Xh-GP for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2015 20:31:35 +0200 Original-Received: from localhost ([::1]:56577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLy2p-00023q-1I for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2015 14:31:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLy2d-00023k-SN for emacs-devel@gnu.org; Sun, 02 Aug 2015 14:31:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLy2Z-0001HD-Ql for emacs-devel@gnu.org; Sun, 02 Aug 2015 14:31:23 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:34672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLy2Z-0001H8-Jc for emacs-devel@gnu.org; Sun, 02 Aug 2015 14:31:19 -0400 Original-Received: by wibud3 with SMTP id ud3so110903362wib.1 for ; Sun, 02 Aug 2015 11:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=wjCF3rE/nPR2iE2eqEclfjt9yTrX69engiGUYbMYGuE=; b=N7CLVPrilHw0tTjq5wiPnr285Mdvg57Z44ySGgnTdlwyaM7HHCJegLvIh+emLouKmL 7v0I8WJztoiP0lusVtqywRQQqmbh04gsnMoPA+kyaG6xm3OMFGhNRq1tXUvcT47BibGl kRDPbxCf5eUOHlRP5aKnf4ifGrvhPQV7Gw1RWR6MLDtCzWZThirktgf2hAgCRpsw6hlM TFaDTHJXhD4vGX7abU0CJEpAXXFx9Jy882Nw+d6dFl6/TvKxPRLrlGrlRCtnRSKHwwI/ Yfw2XRvK69tcQGGrMZ8GjwT7wDiAHEJuz86efVJxc2AjDjDMMSrEivO/Y+wh8ifyCzvK SFXw== X-Received: by 10.194.175.233 with SMTP id cd9mr26574669wjc.68.1438540278910; Sun, 02 Aug 2015 11:31:18 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id nb9sm9413343wic.10.2015.08.02.11.31.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Aug 2015 11:31:17 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <55BE33AF.6080402@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:188298 Archived-At: On 08/02/2015 06:13 PM, Paul Eggert wrote: > Again, this problem is independent of quoting style, and has long > existed in Emacs evem with the older quoting style. For example: We didn't have an escaping syntax for quotes before. You've increased the complexity of our handling of quoting. Might as well fix some pre-existing problems. Right? Look at it from the user's point of view: quotes can be escaped, it's documented in the substitute-command-keys docstring. And yet, it doesn't help in this kind of situations, where it seemingly should. > (defun foo (a b c) > "It's invoked by `\\[next-error]'." > (+ 1 2 3)) This works now, and would continue to work, as per my suggestion. > Yes, and substituting \[...] has problems and solutions that are quite > similar to substituting ` and '. So even if it makes sense to tease > this functionality apart in some cases, it also makes sense to have a > single function that does both subsitutions for convenience, as > typically programs will not want to do one without doing the other. When both substitutions are required, calling the second function on the result of the first function will be just as easy. Splitting the logic between two functions will make sure the first one doesn't lose information. > It's a simple-enough matter to add an argument to substitute-doc-string > specifying which kinds of substitutions are wanted. I can volunteer to > do that if it would be helpful (though I confess I don't see the use > case). It's better to keep the quote translation logic in one place (in a different function). > Or if you prefer you can rewrite substitute-doc-string in Lisp > -- as long as it doesn't affect performance significantly that should be > merely an implementation detail. Rewriting it also requires some C chops, if only to read the original. I don't know whether it'll lose performance: it might, handing certain keymaps might be intensive. Anyway, even if the resulting function is in Lisp, it won't help as long as it's just one function, and it still loses information about which characters were originally escaped. > I mentioned the possibility because it's still not clear to me what a > Lisp solution would be, if it's not something involving font-lock. If > the Lisp solution merely translates the existing C code to Lisp, then of > course your point is correct. The Lisp solution would replace actual characters with different characters. In the text, not apply the transformation via text properties (although that's also an option).