[Top][All Lists]

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

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

From: Alan Mackenzie
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Mon, 8 Jun 2015 17:18:04 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Paul.

On Sat, Jun 06, 2015 at 05:09:13PM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > Up till now, all messages output have been ASCII (with the exception of user
> > supplied characters and in some other rare instances such as outputting
> > `sentence-end').

> No, even the current stable version of Emacs (24.4) regularly outputs
> curved quotes on typical displays.  I just now ran emacs -Q, typed "C-h
> i m emacs RET", and saw curved quotes on the first screenful of the
> Emacs manual.

The topic was specifically "message output".  And up till now this has
been ASCII.  Saying "somebody else did it first, therefore it must be all
right for us" is a red herring.  I hope you never use that as an excuse
in a court of law.  Further, we don't control Info output, there's
nothing much we can do about it, and you have been amongst the loudest
complaining about Info 5, albeit about a different aspect.

> So we're not making such a drastic change here; we're just evolving
> Emacs in the natural direction.

Sorry Paul, but that's not so.  There's nothing "natural" about
"evolving" from ubiquitous common characters to obscure, difficult to
type, difficult to display ones.  The change in philosopy is marked.
"There's a massive movement afloat, and we're just allowing ourselves to
be swept along with it" isn't the Emacs norm.

What you want to do is to change Emacs so that it works less well on many,
if not most[*], current setups.  The one justification you've given is that
you personally find the current use of ASCII quote marks irritating,
which I would accept as a good reason, but you could fix that by fixing
your fonts, in much the same way you're advocating I fix my fonts.  I
don't think "everybody else is doing it" counts as justification at all.

[*] Even on GUI systems with all these quirky characters displayable,
it's going to be more difficult to do search operations involving them.

> > does the code test the output display setup to decide what sort of
> > quotes to output (best), or is it up to some user option (middling)
> > or is it hard coded (worst)?

> It tests the output display setup.

Excellent!  I've just updated and built my master copy, and tried it out
on the Emacs manual as bundled with the 24.5 release.  That still
displays double curly quotes as inverse question marks, though.  Could I
have misunderstood you, and the code that does this test hasn't yet found
its way into master?

> >> This is not too much to ask of an Emacs developer.

> > Of course not, but could it be too much to ask of an Emacs user?

> Emacs users in 8-bit environments shouldn't need to worry about this; they 
> should just see straight quotes where the Emacs manual etc. uses curved ones. 

And they'll see C-s searches involving "these" characters failing
inexplicably.  And this will happen in more than just "8-bit"

> This thread is more about the special case of a developer who's using a Linux 
> console that doesn't support the full Unicode gamut.

It's potentially about the "special case" of USERS of all display
environments other than unicode GUI ones.  How many environments other
than the Linux terminal are there in which these new characters won't be
displayed properly?  As the proponent of the change, you'll surely have
done this research, yes?.

> > this warrants an extensive entry in NEWS.

> Makes sense, and the next iteration of this patch will add a NEWS entry.

> > I don't think that's the font for me.  It has one-pixel thick spidery
> > characters, rather than the two-pixel thick ones the default fonts have.

> The font has a bold variant.  I'll attach Lat15-TerminusBold16.psf.gz.  There 
> are other variants that are even bigger, if you like.

I don't think it makes too much sense to talk about my personal setup.
I've already resigned myself to spending many hours on the topic, and
finding out about how Linux console fonts work has already consumed the
first few hours of this.  The real question is what support is to be
given to the bulk of other users of non-full-unicode terminals.

> > ... Its apostrophe is a vertical line rather than a top right to bottom left
> > sloping character, and I find its curly single quotes too indistinct

> If you just want to continue to use the same font, how about the attached 
> font 
> lat1-16.psfu.gz instead?

That's the one I'm using anyway.  :-).  It's an excellent font, but it
lacks curly double quotes and distinct glyphs for curly single quotes.  I
have the requisite programs for editing fonts, namely psf2txt, and
txt2psf, part of the GNU/Linux psftools package.  psf2txt dumps a font
into a readable (and editable) format, and txt2psf does the reverse.

> It's taken from the current stable version of kbd 
> <http://kbd-project.org/>; see 
> <http://kbd-project.org/download/kbd-2.0.2.tar.xz> and extract the file 
> kbd-2.0.2/data/consolefonts/lat1-16.psfu and then use gzip to get the 
> compressed 
> version.  This handles curved single quotes and if it's the same lat1-16 font 
> you're used to you should find it comfortable.  Curved double quotes don't 
> come 
> up as often, but if you want them to be displayed using a graphical 
> representation other than '"', you can do something like the following:

> (printf '0x0d3 U+201C\n0x0d9 U+201D\n'; psfgettable lat1-16.psfu) |
> psfaddtable lat1-16.psfu - lat1-16-double.psfu
> gzip -9n lat1-16-double.psfu

> and then use the font lat1-16-double.psfu.gz instead.

This, indeed, is another approach.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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