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: A simple solution to "Upcoming loss of usability ..." Date: Thu, 25 Jun 2015 19:35:42 -0700 Organization: UCLA Computer Science Department Message-ID: <558CBA7E.7060900@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1435286174 30613 80.91.229.3 (26 Jun 2015 02:36:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 02:36:14 +0000 (UTC) To: Dmitry Gutov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 26 04:36:05 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 1Z8JUp-0000Mg-Ic for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 04:36:03 +0200 Original-Received: from localhost ([::1]:58041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8JUo-0003UQ-M5 for ged-emacs-devel@m.gmane.org; Thu, 25 Jun 2015 22:36:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8JUj-0003UI-KF for emacs-devel@gnu.org; Thu, 25 Jun 2015 22:35:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8JUf-0001QL-AF for emacs-devel@gnu.org; Thu, 25 Jun 2015 22:35:57 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8JUe-0001QD-SV for emacs-devel@gnu.org; Thu, 25 Jun 2015 22:35:53 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0DB1D160848; Thu, 25 Jun 2015 19:35:52 -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 U6d_w4uGQg0n; Thu, 25 Jun 2015 19:35:51 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 03D3316084C; Thu, 25 Jun 2015 19:35:51 -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 yf9SMON9I4HL; Thu, 25 Jun 2015 19:35:50 -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 D95D9160841; Thu, 25 Jun 2015 19:35:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <558C82D2.1070408@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:187551 Archived-At: Dmitry Gutov wrote: > This is just hand-waving. I gave you a patch, feel free to criticize it= , ask to > support different cases, etc. I think the most recent patch you sent is in=20 . I= just=20 now tried it against the current master (commit=20 99ad90dcb1beccde926d9b6475a393c6f8743f5c), and didn't notice any differen= ce in=20 display. I suppose you intended the patch to be combined with reverting = some=20 recent changes to the master, but I don't know which changes those would = be. Also, as I understand it this part of the thread was about display of Eli= sp=20 source code, whereas that patch seems to about display of *Help* buffers. > You can display a wrong character with sustitute-command-keys just as w= ell. Yes, of course. But in practice the effect of substitute-command-keys is= =20 limited to strings displayed in *Help* buffers. This makes its misbehavi= or less=20 likely (and when it happens, less of a problem) than a font-lock approach= =20 designed to display arbitrary Elisp source code. > Like in its own docstring currently ("Each =E2=80=98 and =E2=80=99 are = replaced by..."). I don't see any wrong character there. That part of the documentation is= about=20 curved single quotes, and that's what I see. > With substitute-command-keys, you can't control the way the characters = look > in the source buffer (which Oleh's patch was for) OK, in that case I agree that the font-lock approach should give more con= trol on=20 how source code is displayed, whereas substitute-command-keys does not af= fect=20 source-code display. I still don't see how font-lock would work with=20 source-code strings containing quotes, though; I expect it will mishandle= =20 display in a significant number of practical cases. (Again, this appears= to be=20 a different topic than the abovementioned patch, so it's not clear what's= being=20 proposed here.) >> No straightforward conversion will work, I'm afraid. > > The logic can follow along the lines of the new parts in substitute-com= mand-keys. That would be plausible if we were talking about *Help* buffer contents,=20 although there's still the matter of dealing with user string contents (w= hich=20 the current master handles but the abovementioned patch seemingly would=20 mishandle). But this part of the thread was about arbitrary Elisp source= -code=20 strings, and the substitute-command-keys heuristics won't work there. > I think we could use "\\", though. Or else, something like "\\=3D", alt= hough that > exact sequence is already taken (substitute-command-keys would eat it). I'm afraid I'm lost now. I don't know what you're proposing here. Your = other=20 comments suggest you're talking about escapes that can appear in any Elis= p=20 source-code string, but I don't know what the escapes look like or what t= hey=20 would do. > font-lock runs in the help buffers, as well as info (if I'm not mistake= n), so that approach can be used in those too. This makes it sounds like you want one font-lock solution for help buffer= s,=20 another font-lock solution for info buffers, and a third font-lock soluti= on for=20 Elisp source-code files. Is that the idea? But I'm having trouble seein= g what=20 the three would have in common or how their combination would be document= ed.=20 For example, for a typical user what would font-lock do for info files th= at is=20 not already being done? >> OK, that can be the format-message function already discussed. > > Indeed. I'll look into implementing that then, as this issue seems separable from= the=20 others.