GNU bug report logs - #20707
[PROPOSED PATCH] Use curved quoting in C-generated errors

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 20707 <at> debbugs.gnu.org
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Fri, 12 Jun 2015 16:46:09 -0700

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.

Previous Next

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