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

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

bug#20707: Use curved quoting in C-generated errors


From: Andy Moreton
Subject: bug#20707: Use curved quoting in C-generated errors
Date: Thu, 11 Jun 2015 14:06:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt)

On Wed 10 Jun 2015, Paul Eggert wrote:

> Alan Mackenzie wrote:
>
>> You want to
>> promote difficult-to-type and problematic-to-display characters to the
>> status of standard "working characters".
>
> The problems aren't that serious.  Display problems are limited to obsolete
> environments that hardly anybody uses because they're so awful, and even there
> we have workarounds.

Please don't project your own experience onto the wider emacs community.
Their usage patterns and experience are almost certainly different to
yours.

> And typing problems aren't a big deal in my Emacs
> environment: for left and right single quotes I normally type a single
> keystroke, without any control or shift or meta keys.  (This is because I use
> Electric Quote mode.)  Other typing environments are also available that work
> nearly as well (using Alt-[ and Alt-] for the two characters, if your Alt key
> works).

Again, you underestimate the difficulty of typing these characters in
other environments. C-x 8 RET LEFT DOUBLE QUOTATION MARK is a pig to
type compared to having a single keystroke for a character printed on a
keycap.

Having tried Electric Quote mode briefly:
a) `electric-quote-local-mode' should be named `electric-quote-mode'
b) `electric-quote-mode' should be named `global-electric-quote-mode'
   and possibly be implemented with `define-globalized-minor-mode'
c) The mode seems to convert ` to a curly quote regardless of context,
   but it would make more sense if it only converted matched pairs
   of `' style quotation.

> I'm not expecting everyone to use these keyboard methods right away.  There
> will be a transition period, and perhaps other, better methods of dealing this
> will emerge.  However, there should be no obstacle to people who do want to
> use those methods.

I have no objection to providing optional ways to use curved quotes
according to local tastes. however you are foisting this on the entire
emacs community as a default setting without having done enough work on
the compatibility issues.

>> I have a feeling you're intending to argue for making the use of curly
>> quotes in our Lisp files standard.
>
> Yes, of course.  It should be normal to type quotes as themselves in doc
> strings.  It's basic WYSIWYG.

You seem to have confused representation and presentation. It is
reasonable to allow presentation to use curved quote characters, even if
the underlying representation is still using `' style quoting. Changing
the representation seems to bring only problems with backward
compatibility.

>> 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\'
>
> I considered doing that, but there were problems.  First, it would make doc
> strings harder to read.  For example, this:
>
> "Setting this attribute will also set the \`:family\',
> \`:foundry\', \`:width\', \`:height\', \`:weight\', and
> \`:slant\' attributes."
>
> is harder to read than this:
>
> "Setting this attribute will also set the ‘:family’, ‘:foundry’,
> ‘:width’, ‘:height’, ‘:weight’, and ‘:slant’ attributes."
>
> Second, the new escapes would cause mental overload with similar
> already-existing uses (e.g., ?\`, "\\`").  Third, and most serious, is that
> the new escapes would mean that string literals are not constants but are
> instead expressions whose values depend on runtime context, and this would
> affect everything: how the byte-compiler works, for example.
>
> To avoid the most serious problem, I considered a simpler idea: have the Lisp
> reader treat \` and \' as curved single quotes in strings.  However, this
> still has the basic problem of being hard to read.  It is needless work to add
> a hard-to-read and nearly-ubiquitous feature merely to cater to obsolete
> platforms.  It's simpler to use quote characters to represent themselves.

It is needless work to break existing systems by introducing a
deliberate regression.

If there is any translation, it should only happen with doc strings at
the point that they are prepared for display. Leaving the underlying
representation alone and only changng how those strings are presented is
far less likely to cause problems.

    AndyM







reply via email to

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