[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20385: [PATCH] Support curved quotes in doc strings

From: Paul Eggert
Subject: bug#20385: [PATCH] Support curved quotes in doc strings
Date: Fri, 15 May 2015 14:13:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]