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

[Alan Mackenzie <acm@muc.de>]

Hello again, Paul.

On Tue, Jun 09, 2015 at 04:42:33PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> >> Curved single quotes are also "working" characters, both in Emacs
> >> >(master branch) and in Texinfo (latest stable version).
> > They're not

> It sounds like your definition of "working" differs from what I thought it 
> meant.

I had thought an informal definition with examples would suffice.  Seems
not.  How about a "working character" being "a character it's easy to
work with"?  That would involve it being easy to type on some standard
keyboard, and being displayable on "all" standard display environments.

> I thought you were using "working" to mean that a character has a 
> special function in Emacs or in the file that one is editing.  But as I 
> understand it now, by "working" you mean that it's a character on your keyboard. 
>   If so, then yes, you're right, curved single quotes are typically not 
> "working" characters.  But I fail to see the significance of this point.

Imagine a keyboard where _all_ characters had to be input by giving their
ASCII (or unicode) code.  That would be hellish, and completely unusable
by any normal person.  Now scale that back a bit, so that only _some_
characters need to be input by code.  That's bad if you use these
characters.  That's like the situation you want to create.  You want to
promote difficult-to-type and problematic-to-display characters to the
status of standard "working characters".  This will make Emacs less
usable.

> For example, the newline character is not a "working" character on my
> keyboard, but that doesn't mean we should exclude newlines from our
> source files.

Newline isn't a "character" in the sense meant.  It does not appear in
any font.  It is more a command than a character.  I admit you could
repeatedly pick holes in any informal definition of "working character" I
give, until we end up with a rigorous, and bearly readable, definition.
That wouldn't be a good use of time for either of us.

> >> >It's true that not every keyboard can generate them in every Emacs
> >> >context with just a single keypress, ....
> >> >but that's also true for many ASCII characters.
> > Also untrue, for the large class of keyboards which are based on the
> > Latin alphabet.

> I have such a keyboard, and when I type Return, Emacs doesn't put a carriage 
> return into a typical buffer; it does something else.  Or when I type the \ key 
> in a Lisp string, Emacs doesn't put a \ into the string; it does something else. 
>   Or when I type a space character when searching, Emacs doesn't search for a 
> space; it does something else.  In all these cases, if I really want to get 
> exactly the ASCII character in question, I have to do something other than type 
> a key labeled by that character.  And my point was that this is something that 
> many ASCII characters have in common with curved quotes.

That's a total diversion.  In normal typing, the characters embossed on
your physical keys are what you see when you type them.  I put it to you
that you don't have any of the four curly quote characters embossed on
any key on your keyboard, and you have no easy way to type them.  I.e.
they're "display characters" even for you.  You have no problem
whatsoever typing \ or space.

I have a feeling you're intending to argue for making the use of curly
quotes in our Lisp files standard.  That would be a backward step for
usability.  

Anyway, here's another idea for making curly quotes in lisp code
optional: an escaped 0x27 or 0x60 in a string should be translated by the
reader to the appropriate ASCII or curly quote, depending on the user's
configuration.  So a doc string might contain this:

    \`foo-bar\'

, and would become ?foo-bar? on your system and `foo-bar' on mine.  That
way, the quotes are still visible in the source as quotes, and the extra
space taken up is minimal, in fact no more than when a " needs to be
escaped.  It would also be fully backward compatible with earlier
Emacsen.  A slight disadvantage would be that users would have to compile
the lisp sources when building a new Emacs.  There are fewer than 61004
occurrences of `...' in our sources.

This could make the extra effort involved in adapting the C source to
handle --with-curly-quotes worthwhile.

> > the standard default Linux console font, default8x16

> It's news to me that this is the standard default Linux console font.  It's not 
> available in Ubuntu or in Fedora, which are popular GNU/Linux distributions.

It's a first class member of the set of fonts distributed in the source
from http://freshmeat.net/projects/kbd/.  It's certainly the default in
Gentoo, quite likely in other distros, too.

> Perhaps it's something used at a low level while booting?  That would make 
> sense, if it uses the same encoding that the IBM PC used back in 1981.  Anyway, 
> it doesn't seem to be of much practical relevance to this thread.

Getting back on topic, we agreed yesterday that things should "just
work", and that users should not have to fiddle around with fonts.  If
you make this change, then fiddling around with fonts is precisely what
some users are going to have to do.

Again, I think the only justification for the change you've given is that
you personally don't like the look of 0x60 and 0x27 used as quote
characters.  Is that really sufficient justification for the loss of
usability we would all face, and the problems with fonts which a subset
of users would be faced with?  With my new idea above for `...' in lisp
files, how about reconsidering my "Q" C macro from a few days ago?

-- 
Alan Mackenzie (Nuremberg, Germany).