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: A simple solution to "Upcoming loss of usability ..." Date: Fri, 26 Jun 2015 01:38:10 +0300 Message-ID: <558C82D2.1070408@yandex.ru> References: <87egkzg7gb.fsf@gmail.com> <558C2E25.10303@cs.ucla.edu> <558C492E.9000705@yandex.ru> <558C7DE1.4060507@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 1435271942 15998 80.91.229.3 (25 Jun 2015 22:39:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 22:39:02 +0000 (UTC) To: Paul Eggert , Oleh Krehel , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 26 00:38:48 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 1Z8Fn7-0001AP-SA for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 00:38:42 +0200 Original-Received: from localhost ([::1]:57659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Fn7-0002AB-9L for ged-emacs-devel@m.gmane.org; Thu, 25 Jun 2015 18:38:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Fms-0002A4-HN for emacs-devel@gnu.org; Thu, 25 Jun 2015 18:38:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8Fmo-0007yc-EF for emacs-devel@gnu.org; Thu, 25 Jun 2015 18:38:26 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:33538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Fmo-0007xA-7u for emacs-devel@gnu.org; Thu, 25 Jun 2015 18:38:22 -0400 Original-Received: by wiwl6 with SMTP id l6so30570367wiw.0 for ; Thu, 25 Jun 2015 15:38:12 -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=z21pMMNrl0spMoIjR3r56VXtPqrDQYboFGBTKCTby6A=; b=GB5JwXUFgSap/3WsbQXMGCJzTjn7GLUwY6dmgCQUjxlnhrBjTU1C7Yr5btPtvMZXdY PXaiAzkARFoLW7zY8SGM+va9H7UQ/+UAPe4eR4Dkk0MrmkB5/wAqL6d4iQeG7O0Wc6pm XRuAAu3+5L/8wmMxHTmtYNRXaZJSUJxGwJ6Msx2b2Fp/7OS5ZtQ1UfztG0v5hVrySOqy onoKNloNdDfuK2DMB/b+aUE6rv9/HqsHoMrmFihbqse/lfhFlOPClm0NRWg5bHCUDVcP vmU1mcrm/iu3UrpnU1+Nm7A9O+xeqbzi41mRJsbkw4/Gp/j7/WjMMIVXR+utT7JCKgqk 2q0g== X-Received: by 10.180.228.6 with SMTP id se6mr9526046wic.33.1435271892601; Thu, 25 Jun 2015 15:38:12 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id m4sm47797260wjb.37.2015.06.25.15.38.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 15:38:12 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <558C7DE1.4060507@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::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:187540 Archived-At: On 06/26/2015 01:17 AM, Paul Eggert wrote: > Perhaps some complex regular expression would work most of the time. > We'd have to see. However, its complexity will make its behavior hard > to document, and it will likely lead to counterintuitive display of > source code on occasion. It's a minor thing to get a color wrong; it's > a bigger deal to display the wrong character. The resulting problems > are likely not to be worth the aggravation. This is just hand-waving. I gave you a patch, feel free to criticize it, ask to support different cases, etc. You can display a wrong character with sustitute-command-keys just as well. Like in its own docstring currently ("Each ‘ and ’ are replaced by..."). > As I said, action-at-a-distance is not a fatal objection. But yes, that > behavior of double-quote is objectionable, and I wish that Emacs didn't > do it. I don't see a way how Emacs would be able not do it. > Third-party code doesn't need to change. It'll still work reasonably well. Then we'll be in the "double standard" area. >> We can keep it disabled by default, if you like. Unlike the >> substitute-command-keys approach, font-lock is flexible that way. > > Sorry, I don't understand this remark. Both approaches allow for > defaults, and for behavior to be disabled by default, so neither has an > advantage in that respect. With substitute-command-keys, you can't control the way the characters look in the source buffer (which Oleh's patch was for). Only how they look in the Help buffer.