From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: 20707@debbugs.gnu.org
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Wed, 10 Jun 2015 09:20:26 -0700 [thread overview]
Message-ID: <557863CA.8060609@cs.ucla.edu> (raw)
In-Reply-To: <20150610133931.GA3632@acm.fritz.box>
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. 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).
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 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.
> 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.
> Again, I think the only justification for the change you've given is that
> you personally don't like the look
It's not just me personally. The rest of the world has moved on. At this point
when outsiders look at Emacs they see mysterious and inappropriate and
off-putting quoting. And this sort of thing has been happening for a while.
See, for example:
http://www.trilithium.com/johan/2005/07/quotation-marks/
next prev parent reply other threads:[~2015-06-10 16:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 7:39 bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors Paul Eggert
[not found] ` <mailman.4052.1433144480.904.bug-gnu-emacs@gnu.org>
2015-06-01 10:49 ` Alan Mackenzie
2015-06-01 16:01 ` Paul Eggert
2015-06-01 17:17 ` Alan Mackenzie
2015-06-01 18:50 ` Paul Eggert
2015-06-02 11:56 ` Alan Mackenzie
2015-06-02 13:25 ` Drew Adams
2015-06-02 15:39 ` Paul Eggert
2015-06-02 15:51 ` Dmitry Gutov
2015-06-02 20:05 ` Paul Eggert
2015-06-02 17:07 ` Alan Mackenzie
2015-06-02 20:44 ` Alan Mackenzie
2015-06-04 15:43 ` Paul Eggert
2015-06-06 15:54 ` Alan Mackenzie
2015-06-06 18:11 ` Paul Eggert
2015-06-06 20:50 ` Alan Mackenzie
2015-06-07 0:09 ` Paul Eggert
2015-06-08 17:18 ` Alan Mackenzie
2015-06-09 6:53 ` Paul Eggert
2015-06-09 13:34 ` Alan Mackenzie
2015-06-09 20:49 ` Paul Eggert
2015-06-09 22:46 ` Alan Mackenzie
2015-06-09 23:42 ` Paul Eggert
2015-06-10 13:39 ` Alan Mackenzie
2015-06-10 16:20 ` Paul Eggert [this message]
2015-06-10 17:39 ` Dmitry Gutov
2015-06-10 19:42 ` Paul Eggert
2015-06-10 19:17 ` Alan Mackenzie
2015-06-10 19:44 ` Paul Eggert
2015-06-11 19:06 ` Alan Mackenzie
2015-06-12 2:41 ` Paul Eggert
2015-06-12 11:25 ` Alan Mackenzie
2015-06-12 23:46 ` Paul Eggert
2015-06-13 11:54 ` Alan Mackenzie
2015-06-13 17:54 ` Paul Eggert
2015-06-07 13:17 ` Wolfgang Jenkner
2015-06-09 16:58 ` Alan Mackenzie
2015-06-02 23:26 ` Paul Eggert
2015-06-01 14:34 ` Eli Zaretskii
2015-06-01 16:48 ` Glenn Morris
2015-06-01 17:55 ` Paul Eggert
2015-06-01 18:29 ` Eli Zaretskii
2015-06-01 21:13 ` Stefan Monnier
2015-06-09 19:44 ` Wolfgang Jenkner
2015-06-11 13:06 ` bug#20707: " Andy Moreton
2020-08-12 13:02 ` bug#20707: [PROPOSED PATCH] " Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=557863CA.8060609@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=20707@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).