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 00:05:54 +0300 Message-ID: <55BD34B2.5060001@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1438463184 20724 80.91.229.3 (1 Aug 2015 21:06:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Aug 2015 21:06:24 +0000 (UTC) To: Paul Eggert , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 01 23:06:16 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 1ZLdyy-0000y2-Dk for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 23:06:16 +0200 Original-Received: from localhost ([::1]:54712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLdyx-0000SM-M4 for ged-emacs-devel@m.gmane.org; Sat, 01 Aug 2015 17:06:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLdym-0000S8-47 for emacs-devel@gnu.org; Sat, 01 Aug 2015 17:06:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLdyh-0002pX-Sj for emacs-devel@gnu.org; Sat, 01 Aug 2015 17:06:04 -0400 Original-Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:33931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLdyh-0002pJ-Ly for emacs-devel@gnu.org; Sat, 01 Aug 2015 17:05:59 -0400 Original-Received: by wibud3 with SMTP id ud3so93858769wib.1 for ; Sat, 01 Aug 2015 14:05:59 -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=yEkbOnqpsAL100yvLRiEmNQ+0WGnyQ6y38GFkPVCsUs=; b=YUVNtq8Bb0VRrZ4XzG2tgrzLmb7YHkTuIOsJUqZNzLmZTNLZqVVONwOdqhgQeHrlD3 RHQHphv7BMgJtRMWO49bAfVtnZ4g0WQJzEaZD7k4NpZN7lt9WuAvmPVRBeviCb4YVn/k csJa3MARiVA6Cm3IBo/MApketleeuA79NC5ib2K8iJZYsOz+Hn/ZCjkrnaCv3+Huk8DL bE5gT8VQ8zBn316ks1aPJTMMrTKf6LGRLIOgp4568A6/+vHg/B0QgK3cBHFtxJc7dcSk /yD+SpnSHpPyO6qlOBglWidRIejwUyscnm3JX8REVlPcg45ER6CtZSCn7rX2m6DOpcPZ YIBg== X-Received: by 10.180.83.137 with SMTP id q9mr20770310wiy.68.1438463159064; Sat, 01 Aug 2015 14:05:59 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id kb1sm14245861wjc.24.2015.08.01.14.05.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Aug 2015 14:05:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <55BC22BB.4020002@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::22c 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:188284 Archived-At: On 08/01/2015 04:36 AM, Paul Eggert wrote: > We can cross that bridge if we ever need to come to it. Such a use > can't be the default everywhere, since not every platform supports > colors and faces (e.g., batch diagnostics). So we'll need something > with quotes anyway. And we already have code that highlights the > contents of quotations so that may well be good enough. It doesn't need to be the default, or the default everywhere. But for it to be feasible to implement at least in some places, substitute-command-keys shouldn't translate the quotes. It should limit itself to translating just the constructs it translated before, as well as putting `escaped' text property on some characters in the output string. >> C code is perfectly able to use Lisp functions. > > I expect that some of the diagnostics are at a low level, and can't > assume that Lisp functions are callable, and that we'll need to do some > of this at the C level regardless. Once it's done there, why bother > with redoing it in Lisp? Highlighting is performed in Lisp. Linkification is performed in Lisp. For instance, help-make-xrefs scans the Help buffer, the contents of which have already passed through substitute-command-keys, for matches of help-xref-symbol-regexp. Without knowing which quotes were escaped, and which appeared in the docstring as-is, it can make wrong cross-references. Take this definition: (defvar foo nil "Referencing `\\=`--pcase-macroexpander' macro.") The references to the function name is not linkified, and to solve this problem better in general, Lisp will need to know which characters were escaped and which weren't. Here's a contrived example which can't be fixed without that: (defun ’‘ (a b c) "It's called `’‘'." (+ 1 2 3)) Of course, we don't have any functions with curly quotes in the name now. But weren't some people just recently clamoring for wider use of Unicode in Emacs Lisp sources? > Whether substitute-command-keys does it directly, or via calling some > other function, is an implementation detail and it's not clear to me yet > which is the right way to go here. It shouldn't perform the translation at all. Not directly, nor via another function. Its callers can do the translation better, and maybe in different ways, depending on the context.