From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#20385: [PATCH] Support curved quotes in doc strings Date: Fri, 15 May 2015 14:13:58 -0700 Organization: UCLA Computer Science Department Message-ID: <55566196.40105@cs.ucla.edu> References: <1429555155-4695-1-git-send-email-eggert@cs.ucla.edu> <5552FDAC.4080004@cs.ucla.edu> <55534080.6010400@yandex.ru> <555369FD.30701@cs.ucla.edu> <5553D12F.7000809@yandex.ru> <5554155E.70000@cs.ucla.edu> <55547DC6.3090509@yandex.ru> <5555A4ED.8090500@cs.ucla.edu> <55562BB0.2010605@yandex.ru> <555640E9.4060203@cs.ucla.edu> <55564460.4020208@yandex.ru> 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 1431724525 11263 80.91.229.3 (15 May 2015 21:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 21:15:25 +0000 (UTC) To: Dmitry Gutov , 20385@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 15 23:15:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1YtMwr-0000Z7-E5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 May 2015 23:15:13 +0200 Original-Received: from localhost ([::1]:33015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMwq-0003Af-AA for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 May 2015 17:15:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMwm-00038f-1c for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 17:15:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtMwh-0007m9-7u for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 17:15:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMwh-0007lM-5g for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 17:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YtMwg-00015c-Nl for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 17:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 21:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20385 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 20385-submit@debbugs.gnu.org id=B20385.14317244504100 (code B ref 20385); Fri, 15 May 2015 21:15:02 +0000 Original-Received: (at 20385) by debbugs.gnu.org; 15 May 2015 21:14:10 +0000 Original-Received: from localhost ([127.0.0.1]:46522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMvp-000143-EH for submit@debbugs.gnu.org; Fri, 15 May 2015 17:14:09 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:57176) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMvm-00013R-DJ for 20385@debbugs.gnu.org; Fri, 15 May 2015 17:14:07 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 05F50A60001; Fri, 15 May 2015 14:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb8Hv6FgCfxd; Fri, 15 May 2015 14:13:59 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3518639E8014; Fri, 15 May 2015 14:13:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <55564460.4020208@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102845 Archived-At: On 05/15/2015 12:09 PM, Dmitry Gutov wrote: > Then there's no need to worry too much about the diagnostic messages. > No, that doesn't follow. For example, suppose that the display supports curved quotes (the typical case) but we use some other format in the source code. Then, cutting from diagnostic output and pasting into the source code won't be intuitive and won't work without some Rube Goldberg conversion. In contrast, if we use curved quotes in the source, cutting and pasting will work naturally. It's true that here if the display doesn't support curved quotes (the atypical case) then cutting and pasting may not work -- but that's not a problem we need to worry about, since it's rare nowadays particularly among developers. > What's there to explain? Quoting will work as before, it'll only be > displayed differently (and users could even opt out of that). That will all require explanation, indefinitely. And this won't be as easy as one might think, particularly if opt-out is common. >> For example, you can easily cut and paste from the UI into the doc >> string source when composing a new doc string, which is something that >> doesn't work well for either GCC or Coreutils. > > Why wouldn't that work in Emacs either way? I suppose it might work in some cases (killing and yanking within a single GUI Emacs, say) but not in others (cutting from one Emacs running remotely under gnome-terminal and pasting into another in a different locale). The other cases are common enough that they will be a continuing hassle. > The only place that seems like it'll have this problem is the Info buffers This sounds backwards. Even now, one can cut curved quotes from an Info file and paste them into a .texi file and it will work, on a typical system with proper UTF-8 support (and assuming the latest Emacs on the master branch and Texinfo 5). (Just to be clear, I'm not proposing that we switch to this .texi style now -- it's not needed for proper use of grave accent and apostrophe in our documentation, and so it's a separate thing that can be deferred for many years.) >> For example, the documentation for prettify-symbols-mode >> uses UTF-8 curved double-quotes. > > Does it? I can't find that. Sorry, I meant tildify-space. (I mixed up functions: prettify-symbols-mode uses a different Unicode character, namely ≤.) > But either way, allowing unicode in sources (why we do, obviously) and > using unicode characters as ubiquitous markup are two very different > things. Yes, they are different in terms of degree. The existing minor uses of UTF-8 in doc strings are merely evidence that UTF-8 works in doc strings. Had these uses been there 20 years or go, or even 10, we would have had significant problems in practice; but nowadays, UTF-8 is not a problem. > If we use rendering via font-lock, there will be no transition process. I'm not so sure, given the cutting-and-pasting issues mentioned above. But even if you're right there would still be a tradeoff: would we want a trivial transition now to a complex and klunky approach long-term, or a nontrivial transition now to a simple and intuitive approach long-term? Let's strive for simplicity.