GNU bug report logs - #16292
24.3.50; info docs now contain single straight quotes instead of `'

Previous Next

Full log

Message #93 received at 16292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: grfz <at> gmx.de, monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org
Subject: Re: bug#16292: 24.3.50;
 info docs now contain single straight quotes instead of `'
Date: Fri, 03 Jan 2014 10:03:11 +0200

> Date: Thu, 02 Jan 2014 16:44:10 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> 
> Eli Zaretskii wrote:
> > These are very rare (and I would argue will look ugly any
> > way you typeset them).
> 
> They're not that rare: for example, I count 949 info lines
> containing both straight and the curly apostrophes, with
> many opportunities for confusion.

That's rare in my book: just the 2 Emacs manuals weigh in at 124800
lines.

> ‘C-x '’ may look ugly on some displays, but it's typically legible,
> and it's definitely easier to grok than 'C-x ''.

We've been living with `C-x'' forever, so I don't see a serious
problem here.  And if we really care, we can customize
OPEN_QUOTE_SYMBOL in Texinfo 5.

> > I don't see the problem: just don't edit any letters, only edit
> > apostrophes, quotes, and arrows.  What am I missing?
> 
> Info generates lots of special characters like that, in
> response to ASCII markup.  From the unibyte reader's point
> of view, why should the output of "``", "@quoteleft{}",
> "@expansion{}", "@result{}", etc. be converted from mojibake
> to ASCII, while the output of "--", "@bullet{}", "@minus{}",
> "@equiv{}", "@~n", etc. remains mojibake?  I don't see any
> systematic principle to distinguish between the two sets of
> characters.

The systematic principle I propose is to convert everything except
letters, i.e. only punctuation and special characters.

> >> The point of cp-ascii is to not put mojibake on unibyte users'
> >> screens, so why not fix all the mojibake while we're at it?
> >
> > To make it more acceptable to UTF-8 locales.
> 
> UTF-8 locales work just fine (actually, better) with the
> original UTF-8 characters, so it's not a priority for
> cp-ascii's output to be more acceptable to UTF-8 locales.

It would be a priority if we decide to make that cp-ascii'd output the
default.

Previous Next

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