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: Thu, 25 Jun 2015 21:32:14 +0300 Message-ID: <558C492E.9000705@yandex.ru> References: <87egkzg7gb.fsf@gmail.com> <558C2E25.10303@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 1435257166 2013 80.91.229.3 (25 Jun 2015 18:32:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 18:32:46 +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 Thu Jun 25 20:32:46 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 1Z8Bx6-0001CT-PS for ged-emacs-devel@m.gmane.org; Thu, 25 Jun 2015 20:32:45 +0200 Original-Received: from localhost ([::1]:57000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Bx5-0005J4-Jj for ged-emacs-devel@m.gmane.org; Thu, 25 Jun 2015 14:32:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Bwr-0005Iy-4Q for emacs-devel@gnu.org; Thu, 25 Jun 2015 14:32:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8Bwn-0004Y4-L8 for emacs-devel@gnu.org; Thu, 25 Jun 2015 14:32:29 -0400 Original-Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:36248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8Bwn-0004X9-E8 for emacs-devel@gnu.org; Thu, 25 Jun 2015 14:32:25 -0400 Original-Received: by wguu7 with SMTP id u7so69736199wgu.3 for ; Thu, 25 Jun 2015 11:32:16 -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=g4ARHRVsJwjtIXbE4wqh4/GBf44eYpzgJnJXBRZX3Qc=; b=UCNmr00EBsgzkiqHgoco9L8b/wrEEFhYCRgtm2nzrvgjB5OaFN4BKnSwk6XBmH7zZv IcwZj69ntzaxErcbqO0OMMu3uBS0ytboZC4Dzd6Z6KTMxE0JZJPmRzIbR8tV04ddzMM/ izocEGg9KBthMSuszxA727mhXOJLbbYSc6NrGpOwnkmR7CKISPo5WD4EA+eu8iMNJP5e qCRcqyjIUtAM0yb1qIl+2ZA0FcK1qkgJ21sBR6X8pLw0FBC0CUvHvPFcXbQdf5SmCMJz E8ZL/5lzy5XaoVkX4zNEcu2RKC2wQ5zNkdvMt/TcEDlS4O/wT5w+QOkP20NzWtVj44Q1 QC6Q== X-Received: by 10.180.20.198 with SMTP id p6mr8312454wie.38.1435257136405; Thu, 25 Jun 2015 11:32:16 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id pl1sm8829847wic.6.2015.06.25.11.32.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 11:32:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <558C2E25.10303@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::22f 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:187529 Archived-At: On 06/25/2015 07:36 PM, Paul Eggert wrote: > The proposed approach would mishandle many cases where the things being > quoted are not typical Lisp identifiers. E.g.: > > "Press ‘h’ for complete help; press ‘?’ repeatedly for a summary" > "Make ‘funcall/apply’ form to map SOURCE-ARGLIST to TARGET-ARGLIST...." > "... Example: ‘(ad-map-arglists '(a &rest args) '(w x y z))’ will return > ..." We already have a different regexp that will handle those. It's not an insurmountable problem either way. > Also, the proposed approach won't easily generalize to diagnostics, > which often quote non-identifiers like ‘%s’. Same here. > There's also a UI problem: > ot would cause action-at-a-distance, because typing an apostrophe in one > place in the buffer would visually alter a part of the line many > characters away. Just like typing a double-quote will make Emacs consider the rest of the buffer a string literal? Not that big a problem. > Most of the advantages you mention for the proposed approach are also > advantages of the approach in master. With the current approach, the > Emacs sources don't need to be changed, Because you already changed them? You'd still have to propagate those changes (which a sizable number of people expressed dislike for), to all third-party Elisp code out there. > The main advantage of the proposed approach over the current master is > that the source code often can still contain grave accent and apostrophe > unmodified, even though people reading and editing the source code will > see curved quotes. To my mind this is more a recipe for confusion than > anything else -- at least, I wouldn't want to inflict it on Emacs > newcomers. We can keep it disabled by default, if you like. Unlike the substitute-command-keys approach, font-lock is flexible that way.