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: Please stop putting curly quotes into doc strings! Date: Wed, 9 Sep 2015 01:23:31 +0300 Message-ID: <55EF5FE3.4020209@yandex.ru> References: <55EA4821.2050401@yandex.ru> <55EBC5B8.80208@cs.ucla.edu> <55EE1B01.3010201@cs.ucla.edu> <55EEDBE7.8050903@yandex.ru> <55EEE97F.1040008@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: 7bit X-Trace: ger.gmane.org 1441751042 16868 80.91.229.3 (8 Sep 2015 22:24:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 22:24:02 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: raman , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 09 00:24:01 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 1ZZRJ0-0008Pb-Ra for ged-emacs-devel@m.gmane.org; Wed, 09 Sep 2015 00:23:58 +0200 Original-Received: from localhost ([::1]:38240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZRJ0-0000YB-JF for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 18:23:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZRIn-0000Y6-W3 for emacs-devel@gnu.org; Tue, 08 Sep 2015 18:23:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZRIk-0007zu-Ta for emacs-devel@gnu.org; Tue, 08 Sep 2015 18:23:46 -0400 Original-Received: from mail-lb0-x22f.google.com ([2a00:1450:4010:c04::22f]:32799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZRIk-0007zm-NK; Tue, 08 Sep 2015 18:23:42 -0400 Original-Received: by lbcjc2 with SMTP id jc2so61425974lbc.0; Tue, 08 Sep 2015 15:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ofiLG/12OUqa4d9GXnZmwjxx8ka2e5yVgTXiTUkkUqc=; b=y1bkZKqYvY5lW4E7rgVXTwPhq+rR1m7YUxF4IMYVT6q8ufdb/6amZ/N5Lg8F2Im7ZV stY+fltdTqt4M1LaSh8+RGNFOuXA8H2Qayh4P8UMWIdyNOwCggOAP6Ehij/4ovaeUSzf rPNwq03kNJHkDz2AuWE/UpqjgWf5YbgrC+wSf1dBcCjoTFP2csHij2Iycz6Yps1Y2i6u 69kHhUS5kHfCn2OstpR4O1YlngDZIdsMMP6rxcj5p3lI+Ee/DTBwnlhCkof6NXsoKxCB xvmfm0l4uIXIfa+gtt2dcxnCCypVD1zBeLWuCuXGMn0RXxqkZ298RwaNuZf/Pcz6yWhq Z91g== X-Received: by 10.112.132.74 with SMTP id os10mr10035745lbb.40.1441751021052; Tue, 08 Sep 2015 15:23:41 -0700 (PDT) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id qh3sm1267978lbb.25.2015.09.08.15.23.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Sep 2015 15:23:40 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::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:189748 Archived-At: On 09/08/2015 07:20 PM, raman wrote: > The negative with that is that we'll have inconsistency between say Core > Emacs libraries and code from Elpa. Exactly. Paul, maybe you can extract the set of pairs to be translated (or highlighted) to a defvar (not defcustom). By default it will be set to ((?` . ?')), but you would be able to add any kinds of pairs. > The needs of developers who view Ascii quotes as ugly and want to see > something else can be easily served by an elpa package that uses all the > tricks you have proposed in reverse on this thread, Unfortunately, I don't see an easy way to write an ELPA package that would do that, barring some new changes, like the one mentioned above. The translation code is written in a non-extensible way, and there's nothing that, say, some new font-lock rules can reuse.