Package: emacs;
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Mon, 1 Jun 2015 07:41:05 UTC
Severity: wishlist
Tags: patch
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Alan Mackenzie <acm <at> muc.de> To: Paul Eggert <eggert <at> cs.ucla.edu> Cc: 20707 <at> debbugs.gnu.org Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors Date: Sat, 13 Jun 2015 11:54:20 +0000
Hello, Paul.
On Fri, Jun 12, 2015 at 04:46:09PM -0700, Paul Eggert wrote:
> 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.
No, from the point of view of somebody who has some feel for how history
works. What you're suggesting is that between the 1960s, when ASCII was
formalised, and the late 1980s, people were desperately waiting for the
development of Unicode so that they could filch the glyphs from it and,
at last, have some way of representing 0x27 and 0x60 as glyphs. That's
patently ridiculous.
> 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.
It's not a matter of "interpretation". 0x27 and 0x60 were there first.
There are fonts where the glphs used for these ASCII characters are
plainly the curly quotes, but few. I'd challenge you to argue that the
following glyph for 0x60 originated as left curly quote:
Bitmap: -------- \
--##---- \
--##---- \
--##---- \
---##--- \
-------- \
-------- \
-------- \
-------- \
-------- \
-------- \
-------- \
-------- \
-------- \
-------- \
--------
> 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.
You're trying to twist facts to fit in with your way of thinking.
> > So far, we've got one data point, me
> No, we've got lots of data points.
By "data points" is meant those who use Emacs on the (Linux) console. I
repeat, the only such user who's expressed a view on your proposed change
is me. If I'm mistaken here, I'd appreciate references to those other
console users' views.
> 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.
That's sophistry. Curly quotes are not currently in use in (released)
Emacs, so of course there's no problem with them yet.
> > 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.
There are 115 console fonts supplied in the kbd package. Only 32 of
them have a glyph for 0x2018 (left curly quote). Of these 32, the glyph
is shared with 0x60 in 15 fonts. All 115 fonts have 0x60.
> 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.
Pure speculation. You're projecting your own attitudes and workflow onto
an unknown number of other users, like Andy Moreton said a couple of days
ago.
The fact is, we don't know one way or the other.
I suspect the majority of these users will care about it, but won't have
the time or the energy to fix it. They will suffer for evermore, just as
you have been suffering the lack of curly quotes. Fixing it is
_difficult_, not easy, for a normal user, since there is no clear entry
into the thicket of Linux documentation - a normal user isn't going to
know that the appropriate utility is setfont, or where to find font
editing software; I certainly didn't up until a few days ago, and it took
a lot of effort to find out.
As I keep saying, this conversion to curly quotes should be optional,
like other controversial new features in Emacs are.
> > 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.
Great. Personally, I don't want it, though - I want to be able to _work_
in *Help* buffers, not merely have them displayed at me. What's the flag
to turn it off called?
> However, this doesn't fix Bug#20707, as it affects only doc strings.
#20707 isn't a bug, in the narrow sense of the word, so doesn't need
fixing. It's a change request.
Anyway, what other strings other than doc strings might want this change?
I've grepped for "\`.*'" and found lots of doc strings, and some `error'
and `message' string arguments like `%s'. Is there anything else?
> >> 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.
I can't recall seeing any instance of Lisp or C code processing doc
strings, or `error' arguments in any way that would make a difference.
Can you cite a specific example?
> Introducing this new compatibility problem would cause trouble into the
> indefinite future.
You still haven't given a specific example of where and how such trouble
might arise.
> It's not worth the extra hassle.
This whole idea of imposing curly quotes on users is extra hassle for
users. Making them optional would, at worst, be extra hassle only for us
maintainers. Which is preferable? For comparison, in Emacs 21, fringes
were imposed on GUI users, without them having a way to turn them off. A
lot of them didn't like it and were up in arms about it. We shouldn't be
repeating that mistake.
--
Alan Mackenzie (Nuremberg, Germany).
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.