bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Thu, 11 Jun 2015 19:06:40 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Paul.

On Wed, Jun 10, 2015 at 12:44:51PM -0700, Paul Eggert wrote:
> On 06/10/2015 12:17 PM, Alan Mackenzie wrote:
> > It seems to me, judging by the number of questions relating to Emacs on
> > the Linux console I've answered over the years, the number of users is
> > not small.

> I'm afraid there was a miscommunication there.  My message was not about 
> people who use the Linux console, a small but hardy band of hackers.

Phew!  I'm glad to hear that!

> It was about people who use the Linux console in an awful mode that
> can't display curved single quotes.  That's not you, and it's not me
> (and I do use Emacs on the Linux console and I haven't configured it
> specially), and I doubt whether it's RMS either.

My setup couldn't display curly single quotes (I've now created a font
based on lat1-16.psfu where I substitued the French glyphs "oe" and "OE"
with the single curly quotes) - instead it lied to me and displayed the
glyphs for 0x60 and 0x27 when there were curly quotes.  This hard linking
of curly and ASCII quotes contravenes the WYSIWYG principle.  I presume
this lack of distinct glyphs will be quite common.

> Perhaps some people use Emacs that way occasionally, but I'm skeptical
> that this is a significant problem.

We simply don't know, one way or the other.

> If it is, we can easily solve it by automatically doing in Emacs the
> equivalent of the font substitution I gave the shell script for in a
> recent message.  So this issue is not a fundamental obstacle to the
> change.

Hmm.  Not sure about "easily".  On a Linux console being used for editing
files.el, we can probably safely assume that all ASCII characters are
available.  More than that, not much.

In fact, I've tried out quite a few different fonts in
/usr/share/consolefonts.  All of them have ASCII, most, but not all,
alias the single curly quotes with 0x27, 0x60, none of them that I've
seen so far have distinct glyphs for the curly quotes.

> > My proposition is that string literals remain constants
> > just as they are now.  The decision would be made at configuration time,
> > and a trivial #ifdef in the reader would decide at build time how to
> > expand the escaped quotes.

> Making them constants removes the most serious objection I had to the 
> idea.  I wouldn't favor writing documentation that way, as it's ugly to 
> quote \`like this\' when it can easily be quoted ‘like this’.

That easiness remains controversial.  Typing \ then ` is going to be in
people's muscle memory, whereas something like <some-modifier-key>-` less
so.  In fact, I'd bet a fair amount that people will carry on writing
`...', just as they've done for decades, and there will be regular
"raids" from the wonderful people here who do finnicky thankless
corrections.

> But it could be useful for people who prefer its minor ugliness to
> having to learn how to type curved quotes, so I suppose we can add it.

To be useful, it would have to become the standard way of quoting
symbols.

> However, the configuration-time switch sounds like a non-starter, as it 
> would be one more source of portability hassles and it shouldn't be 
> needed if we get the display problems fixed, ...

Where do you see any portability hassles?  If built
--without-curly-quotes, Emacs would run under any system handling ASCII,
as at present.  If built --with-curly-quotes, it will be less portable,
as we've discussed at length, but will be no less portable than the
non-optional curly quote system you're proposing.

What exactly do you mean by "display problems fixed"?  Either a font has
curly quotes (I haven't found one, other than my own, which has), aliases
them with other characters, or doesn't have them.  In the first case
there's nothing to fix, while the other two cases can't really be fixed
at all - there are merely workarounds.

> ... which we need to fix anyway.  That is, the escapes should simply
> generate curved single quotes on all platforms.

... which removes half the point in having the \` \' constructs in the
first place.  (The other half is in it being easier to type \` and /'
than ? and ?.)

Incidentally, I've just tried electric-quote-mode in master.  It seems
more like a proof of concept than a finished feature.  In particular, I
don't think it's TRT simply to curlify any quote typed within a string -
some strings mean quite definitely 0x27 and 0x60.  And to be 100% sure
we're within a string is difficult.  How about only curlifying when
there's a matched pair of quotes containing exactly a symbol, and
uncurlifying when that ceases to be the case?

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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