GNU bug report logs - #20385
Support curved quotes in doc strings

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 20385 <at> debbugs.gnu.org
Subject: bug#20385: [PATCH] Support curved quotes in doc strings
Date: Fri, 15 May 2015 14:13:58 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.