From: Drew Adams <drew.adams@oracle.com>
To: "Per Starbäck" <per@starback.se>, emacs-devel@gnu.org
Subject: RE: ASCII-only startup message?
Date: Sun, 27 Dec 2015 14:47:04 -0800 (PST) [thread overview]
Message-ID: <e4e725fd-8b91-40aa-863f-bee71da762f7@default> (raw)
In-Reply-To: <CADkQgvux_N7gLS92-jK3rPsszLo+yPDUQENEyfdUHTg2-U25_g@mail.gmail.com>
> > Or consider character HYPHEN-MINUS (U+002D), character HYPHEN
> > (U+2010), and character MINUS SIGN (U+2212).
> >
> > You might say that the first of these is analogous to the ASCII
> > apostrophe (U+0027) - it is essentially for compatibility.
>
> Yes, that is true, but not for compatibility between "apostrophe" and
> "right single quotation mark" as that imagined argument continues in
> your post, but for compatibility between "left single quotation mark"
> and "right single quotation mark" as well as less common characters
> like "prime".
Huh? The Unicode _name_ of character U+0027 is... "APOSTROPHE".
And the Unicode "old name" of it is "APOSTROPHE-QUOTE".
Claiming that Unicode intends this character only for compatibility
between "left single quotation mark", "right single quotation mark",
and less common characters like "prime", and NOT for compatibility
between "apostrophe" and "right single quotation mark" is, well,
imaginative. Where do you get that notion?
---
And then there is this, which echoes the point I made that an
apostrophe _is not_ a closing quotation mark.
https://tedclancy.wordpress.com/2015/06/03/which-unicode-character-should-represent-the-english-apostrophe-and-why-the-unicode-committee-is-very-wrong/
(cited here, BTW: http://ilovetypography.com/2015/08/07/this-month-in-typography-6/)
Using U+2019 is inconsistent with the rest of the standard
----------------------------------------------------------
Earlier in section 6.2, the standard explains the difference
between punctuation marks and modifier letters:
Punctuation marks generally break words; modifier letters
generally are considered part of a word. Consider any English
word with an apostrophe, e.g. “don’t”.
The word “don’t” is a single word. It is not the word “don”
juxtaposed against the word “t”. The apostrophe is part of the
word, which, in Unicode-speak, means it’s a modifier letter,
not a punctuation mark, regardless of what colloquial English
calls it.
According to the Unicode character database, U+2019 is a
punctuation mark (General Category = Pf), while U+02BC is a
modifier letter (General Category = Lm). Since English
apostrophes are part of the words they’re in, they are
modifier letters, and hence should be represented by U+02BC,
not U+2019.
And this, which makes a somewhat different argument:
https://www.mail-archive.com/unicode@unicode.org/msg35871.html
It refers to the previous argument thus:
Were there no modifier letters at all, Unicode had have to
introduce an apostrophe character, because an apostrophe is
not at all the same as a quotation mark and does not work the
same way neither. By handling text, not theories, Ted Clancy
at Mozilla clearly shows us that ambiguating the apostrophe
with a close-quote brings up counterproductive complications
that impact severely the productivity of the users.
Reply: https://www.mail-archive.com/unicode@unicode.org/msg35851.html
And this URL provides a history of the move from U+02BC to U+0219:
http://charupdate.info/#ambiguation
It points out that this move was so odd that it required the
invention of the word "ambiguation" to cover the confusion.
The same article suggests that the Unicode Consortium itself
"is not at ease with the new preference".
A search in the Mail Archives shows why the apostrophe and the
single close quote were ambiguated—a process that needs even a
new word to put on it, as ordinarily everybody works for
disambiguation. It was for simplification's sake, in word
processing software.
Simplification for word-processing software! Aka MS Word and
its notorious misuse of _left_ single quotation mark for things
like "‘Tis the season" (it should be "’Tis"):
The phenomenon called “the Apostrophe Catastrophe” consists in
a huge number of instances where text processing software (word
processor, desktop publishing) inserts an open quote instead of
a leading apostrophe.
Interestingly, a similar discussion surrounds the use of hyphen:
https://www.mail-archive.com/unicode@unicode.org/msg35852.html
But luckily, the miscategorisation of U+2010 hasn't led to any
pressing practical problems, unlike the misuse of U+2019 for the
apostrophe.
This discussion, BTW, is from _2015_, 16 years after the Unicode
decision to switch from using U+02BC to using U+0219 as apostrophe.
Still problematic, it would seem. Certainly not cut-and-dried.
---
To be clear, I am NOT arguing that _Emacs_ should use U+02BC
instead of U+0219 as apostrophe. I argue that Emacs should
(continue to) use U+0027 (ASCII apostrophe) as apostrophe (in its
own doc, *scratch* comments, and so on). Not because it is a
more genuine apostrophe but because it is much easier for users
(and programs) to work with.
next prev parent reply other threads:[~2015-12-27 22:47 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-26 17:25 ASCII-only startup message? Paul Eggert
2015-12-26 18:16 ` Eli Zaretskii
2015-12-26 18:41 ` Random832
2015-12-26 18:50 ` Paul Eggert
2015-12-26 19:11 ` Eli Zaretskii
2015-12-26 19:01 ` Eli Zaretskii
2015-12-26 18:45 ` Paul Eggert
2015-12-26 19:10 ` Eli Zaretskii
2015-12-26 19:40 ` Paul Eggert
2015-12-26 20:50 ` Eli Zaretskii
2015-12-26 23:28 ` Paul Eggert
2015-12-27 0:17 ` Drew Adams
2015-12-27 1:03 ` Clément Pit--Claudel
2015-12-27 2:51 ` Drew Adams
2015-12-27 1:09 ` Paul Eggert
2015-12-27 15:56 ` Eli Zaretskii
2015-12-27 18:45 ` Paul Eggert
2015-12-27 6:58 ` Random832
2015-12-27 14:17 ` Per Starbäck
2015-12-27 14:55 ` Drew Adams
2015-12-27 16:35 ` Per Starbäck
2015-12-27 17:42 ` Drew Adams
2015-12-27 19:27 ` Per Starbäck
2015-12-27 22:47 ` Drew Adams [this message]
2015-12-27 23:45 ` Per Starbäck
2015-12-28 2:01 ` Drew Adams
2015-12-28 5:51 ` Random832
2015-12-28 10:09 ` Drew Adams
2015-12-28 6:05 ` Per Starbäck
2015-12-28 10:13 ` Drew Adams
2015-12-28 9:12 ` Nikolai Weibull
2015-12-28 10:15 ` Drew Adams
2015-12-28 14:59 ` Nikolai Weibull
2015-12-28 18:39 ` Drew Adams
2015-12-29 9:06 ` Alan Mackenzie
2015-12-28 9:37 ` Paul Eggert
2015-12-28 10:16 ` Drew Adams
2015-12-29 7:05 ` Random832
2015-12-29 8:01 ` Yuri Khan
2015-12-29 14:38 ` Random832
2015-12-29 15:58 ` Eli Zaretskii
2015-12-29 17:05 ` Paul Eggert
2015-12-29 18:00 ` Drew Adams
2015-12-29 18:16 ` Eli Zaretskii
2015-12-29 19:24 ` Paul Eggert
2015-12-29 15:55 ` Eli Zaretskii
2015-12-29 17:40 ` Drew Adams
2015-12-28 16:31 ` Eli Zaretskii
2015-12-27 3:44 ` Eli Zaretskii
2015-12-27 8:12 ` Nikolai Weibull
2015-12-28 20:04 ` John Wiegley
2015-12-29 6:50 ` Richard Stallman
2015-12-29 16:55 ` John Wiegley
2015-12-29 17:30 ` Paul Eggert
2015-12-29 18:18 ` Drew Adams
2016-01-01 13:29 ` Marcin Borkowski
2016-01-01 17:48 ` John Wiegley
2016-01-01 17:50 ` John Wiegley
2016-01-02 8:14 ` Paul Eggert
2015-12-29 15:05 ` Random832
2015-12-29 16:49 ` John Wiegley
[not found] ` <<n5u7gn$6vh$1@ger.gmane.org>
2015-12-29 17:46 ` Drew Adams
[not found] <<567ECD8C.1070408@cs.ucla.edu>
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4e725fd-8b91-40aa-863f-bee71da762f7@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=per@starback.se \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.