bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors


From: Paul Eggert
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Fri, 12 Jun 2015 16:46:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 06/12/2015 04:25 AM, Alan Mackenzie wrote:
No. The curly quotes had hijacked the glyphs for 0x27 and 0x60.

Only from the point of view of someone who prefers an obsolescent style. Nowadays those two glyphs in computer text typically stand for curved quotes. So a more typical interpretation nowadays would be that in that font, 0x27 and 0x60 hijacked the glyphs for curved quotes. Although you prefer the older style (and that is of course your privilege), your console was displaying curved single quotes just fine in the typical way that most people expect nowadays on computer displays.

So far, we've got one data point, me

No, we've got lots of data points. Many people use Emacs 24.5 and later, it displays curved quotes in ordinary use even when users don't type them, and it's not a problem in typical practice.

I think whatever happens, messing around with fonts would be needed for lots of console users

No, it'll work fine for most Linux console users, as most GNU/Linux distributions have console fonts that don't have the aliasing problem. Debian-based distributions are fine, as are Fedora-based distributions. Although you're running on one of the less-common console setups that does have an aliasing problem, it's not a problem that most users of these setups will care about, and anyway it's a problem that's easy to fix, for the rare users who will care.

How about another approach ... translate `foo-bar' to ‘foo bar’ when doing C-h f/v, and so on?

Done in commit 0fd5e6593af620863dcf90dff5d04631458e24cd dated May 28. However, this doesn't fix Bug#20707, as it affects only doc strings.


Code might work when running on a typical Emacs system, but might fail on an
Emacs system configured --without-curved-quotes, because Emacs will generate
different strings that will be treated differently.
I can't see that.  There'd just be displayable characters in the two
versions - why would it matter that they were different?

Code regularly processes such strings, not typically by 'read', more often by applying string or regular expression matching to them. Introducing this new compatibility problem would cause trouble into the indefinite future. It's not worth the extra hassle.






reply via email to

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