From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Escaping quotes in docstrings, Was: A simple solution to "Upcoming loss of usability ..." Date: Tue, 30 Jun 2015 19:56:18 -0700 Organization: UCLA Computer Science Department Message-ID: <559356D2.4000103@cs.ucla.edu> 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> 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 1435719399 29243 80.91.229.3 (1 Jul 2015 02:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jul 2015 02:56:39 +0000 (UTC) To: Dmitry Gutov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 01 04:56:30 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 1ZA8CM-0005YG-Iz for ged-emacs-devel@m.gmane.org; Wed, 01 Jul 2015 04:56:30 +0200 Original-Received: from localhost ([::1]:49451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZA8CL-0005Kv-QP for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2015 22:56:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZA8CG-0005HB-Dw for emacs-devel@gnu.org; Tue, 30 Jun 2015 22:56:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZA8CD-0006rt-KY for emacs-devel@gnu.org; Tue, 30 Jun 2015 22:56:24 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZA8CD-0006rn-C9 for emacs-devel@gnu.org; Tue, 30 Jun 2015 22:56:21 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 03D0A160176; Tue, 30 Jun 2015 19:56:20 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d_I021WXBGdh; Tue, 30 Jun 2015 19:56:19 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 25047160660; Tue, 30 Jun 2015 19:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p6Syxfu71cym; Tue, 30 Jun 2015 19:56:19 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 04427160176; Tue, 30 Jun 2015 19:56:19 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <55908355.3080407@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:187695 Archived-At: Dmitry Gutov wrote: > On 06/28/2015 11:27 PM, Dmitry Gutov wrote: > >> Ok. But I'd rather push to the scratch/quote-escaping branch, if you >> don't mind. > > Check it out. I tried it out. One thing I noticed right away is odd behavior that results from storing grave accent and apostrophe in the buffer and displaying them as curved quotes. For example, run 'emacs -Q -nw', then read the documentation for the 'length' function and copy it to a new file /tmp/foo by typing "C-h f length RET C-x o C-x h M-w C-x 4 f /tmp/foo RET C-y C-s". On the screen you'll see a buffer 'foo' containing curved quotes. Now, revisit /tmp/foo by typing "C-x C-v RET". The buffer will contain the same contents as before, except the curved quotes are magically transformed to grave accent and apostrophe on the display. It's weird that copied text mysteriously changes its display representation at a seemingly unrelated moment. How about the following idea instead. Instead of displaying grave accent and apostrophe specially, have with-help-window transliterate these characters in place before displaying itself as usual. with-help-window should not transliterate characters that are marked as being escaped, or as being user data (not clear that we need two kinds of marks here; one should do, no?). That's the big picture. Here are a few more-minor remarks. > + (font-lock-add-keywords > + nil '(("\\(\\\\~\\)\\(?:\\\\~\\|.\\)" As already mentioned, the new \~ quoting syntax doesn't seem to be needed; we can get by with the existing \= quoting syntax. So let's go that direction. Also, this regexp string matches either (1) \~\~ or (2) \~ followed by any non-newline character. But if \~ is supposed to escape the next character, the regexp string should simply implement that, i.e., the regexp string should be "\\\\~\\(.\\|\n\\)". I assume the extra complication is about escaping backslash itself, e.g., if the docstring is \~\ (which would look like "\\~\\" in the source code) this should stand for \ in the *Help* buffer. But the above regexp doesn't do that. If we were to keep \~ perhaps we could do the simple regexp match first, and then look backwards programatically just before the matching \~ and verifying that either (1) it's not preceded by ordinary ~ or (2) it's preceded by ordinary ~ but the ~ is not preceded by ordinary \. By "ordinary" I mean a character that does not have the help-value or help-tilde-escaped properties. But all and all this is sounding way tooo complicated and we should simply use the same escape sequences we've always been using. > + (unless (get-text-property mbeg 'help-value) Supposed the matched string is partly help-value, and partly not. E.g., mbeg has help-value but mbeg+1 does not but mbeg+2 does. Shouldn't this test that all the matched characters are not help-value characters? > + ;; If we use "" as the third argument, cursor > + ;; stumbles once when moving over its position. I don't understand this comment. Can you explain? For example, does the comment apply to the just the compose-region call, or to the rest of the 'unless'? > + (buffer-substring-no-properties > + mend (1+ mend))) This may go haywire if it returns "\t", because a TAB is special to compose-region. Also, what if the buffer has some properties other than help-value that should be preserved? At this point I stopped reviewing the changes in detail, as really the big picture should be addressed first.