From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: ASCII-only startup message? Date: Sat, 26 Dec 2015 18:51:35 -0800 (PST) Message-ID: References: <567ECD8C.1070408@cs.ucla.edu> <8360zlhy7x.fsf@gnu.org> <567EE043.9020109@cs.ucla.edu> <83y4chgh5q.fsf@gnu.org> <567EED47.1090700@cs.ucla.edu> <83si2pgci8.fsf@gnu.org> <567F22B1.9040702@cs.ucla.edu> <2dc99848-b6d5-4f53-b22c-66e29d15647c@default> <567F38EF.1030908@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451184730 12740 80.91.229.3 (27 Dec 2015 02:52:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 02:52:10 +0000 (UTC) To: =?utf-8?B?Q2zDqW1lbnQgUGl0LS1DbGF1ZGVs?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 27 03:51:59 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aD1R8-0004Tf-Mk for ged-emacs-devel@m.gmane.org; Sun, 27 Dec 2015 03:51:58 +0100 Original-Received: from localhost ([::1]:40566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aD1R7-0003YW-IV for ged-emacs-devel@m.gmane.org; Sat, 26 Dec 2015 21:51:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aD1Qu-0003YO-RR for emacs-devel@gnu.org; Sat, 26 Dec 2015 21:51:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aD1Qp-0002YH-PI for emacs-devel@gnu.org; Sat, 26 Dec 2015 21:51:44 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:34591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aD1Qp-0002YC-HU for emacs-devel@gnu.org; Sat, 26 Dec 2015 21:51:39 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBR2paKj023020 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 02:51:36 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tBR2pZg9027130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 27 Dec 2015 02:51:36 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBR2pZlt003358; Sun, 27 Dec 2015 02:51:35 GMT In-Reply-To: <567F38EF.1030908@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196950 Archived-At: > > I have never seen any doc or typography guideline that favors > > a quotation mark over an apostrophe for English contractions, > > possessives, or non-word plurals. Quite the contrary. These > > use cases are precisely the raison d'=C3=AAtre for the apostrophe. >=20 > I don't know much about this topic, so this may not be the type of docume= nts > you're looking for. Are you aware of the following passage, on page 274 o= f > the latest Unicode standard (page 19 of > http://www.unicode.org/versions/Unicode8.0.0/ch06.pdf)? I believe that Da= vid > Kastrup already quoted it. >=20 > > Apostrophes > > > > U+0027 apostrophe is the most commonly used character for apostrophe. F= or > > historical reasons, U+0027 is a particularly overloaded character. In > > ASCII, it is used to represent a punctuation mark (such as right single > > quotation mark, left single quotation mark, apostrophe punctuation, ver= tical > > line, or prime) or a modifier letter (such as apostrophe modifier or ac= ute > > accent). > > Punctuation marks generally break words; modifier letters generally are > > considered part of a word. When text is set, U+2019 right single quotat= ion > > mark is preferred as apostrophe, but only U+0027 is present on most key= boards. > > Software commonly offers a facility for automatically converting the U+= 0027 > > apostrophe to a contextually selected curly quotation glyph. In these s= ystems, > > a U+0027 in the data stream is always represented as a straight vertica= l line > > and can never represent a curly apostrophe or a right quotation mark. > > > > Letter Apostrophe. > > > > U+02BC modifier letter apostrophe is preferred where the apostrophe is = to > > represent a modifier letter (for example, in transliterations to indica= te > > a glottal stop). In the latter case, it is also referred to as a letter > > apostrophe. > > > > Punctuation Apostrophe. > > > > U+2019 right single quotation mark is preferred where the character is = to > > represent a punctuation mark, as for contractions: =E2=80=9CWe=E2=80=99= ve been here > > before.=E2=80=9D In this latter case, U+2019 is also referred to as a p= unctuation > > apostrophe. > > > > An implementation cannot assume that users=E2=80=99 text always adheres= to the > > distinction between these characters. The text may come from different > > sources, including mapping from other character sets that do not make t= his > > distinction between the letter apostrophe and the punctuation apostroph= e/right > > single quotation mark. In that case, all of them will generally be repr= esented > > by U+2019. > > > > The semantics of U+2019 are therefore context dependent. For example, i= f > > surrounded by letters or digits on both sides, it behaves as an in-text > > punctuation character and does not separate words or lines. >=20 > I understand this as an explicit endorsement of "There=E2=80=99s" over "T= here's", > and of "it=E2=80=99s the _wrong thing_" over "it's the _wrong thing_". M= ark Davis > (the president of the Unicode consortium) clarified this in an email back= in > 1999: http://www.unicode.org/mail-arch/unicode-ml/Archives-Old/UML017/055= 8.html I see, and I thank both you and Paul for that information, of which I was u= naware. I should have checked first the Wikipedia article for Apostrophe, which cov= ers all of this (including the Unicode corner) quite well: https://en.wikipedia.org/wiki/Apostrophe. The topic seems still to be muddy water. Unicode still confuses quotation mark with apostrophe. At least the _role_ of apostrophe (used within a wor= d) is recognized as what I said, as opposed to the role of quotation marks (us= ed around words). But Unicode has apparently decided to consider the _same character_ as appropriate for both uses. Odd that that choice is made over and against the same kind of confusion wrt use of the ASCII apostrophe character, which they rightfully point to as (even more) overloaded in its use ("U+0027 is a particularly overloaded character"). I bend to Unicode's choice in this, of course. But it is too bad, IMO, that it does not distinguish apostrophe and quotation marks in usage, but recommends using the _same character for both uses_. Recommending this, even when they could have done otherwise (ASCII's existing-keyboards excuse does not apply to Unicode choices), seems like a mistake to me. But what do I know? I'm no expert in these things. And Unicode has wider concerns than English typography - similar-looking glyphs apparently have different usages across languages. Perhaps this confounding of apostrophe and quote mark was a compromise of some kind. I do agree that one character for two uses (apostrophe and quotation) is better than one character for several uses, which has been the case for the ASCII apostrophe. I am surprised that two different characters were not defined for these different uses, however, even if they might often have similar or even identical appearances. Oh well. I would still argue for for _Emacs_ to use ASCII apostrophe (and not a quote mark) for apostrophe uses, both on the basis of appearance - at least in the default fonts and in the fonts I use - and (especially) on the basis of simplicity of use for most keyboard users. Emacs is about writing and editing more than it is about presentation-level typography. In terms of appearance, I disagree with Paul's appreciation that "it=E2=80= =99s" is preferable to "it's" in the default Emacs fonts (and more generally in the fonts I use, for Emacs and for technical doc applications). But in any case, I think that ease of use is more important for Emacs than appearance, for this. Anyway, thanks to both of you, again, for teaching me about Unicode's equivalence of apostrophe and quotation mark, and its preference of this character for the uses of an apostrophe. It's not my personal preference for uses of an apostrophe. It's not the preference used (so far) by my company in its technical docs (FWIW). And I don't think it should be the preference for Emacs - which _should_ generally use Unicode, and which should respect its recommendations when appropriate, but which need not bend to using the Unicode right quotation mark as apostrophe. I think (so far) that Emacs should stick to using ASCII apostrophe as apostrophe, in spite of the Unicode standard's recommendation here. And this mainly for simplicity of use, not appearance (though I also prefer the appearance, personally, in the fonts I know). I have now heard Unicode's recommendation (thanks to you), but I don't read the reason given for that recommendation as a strong reason. Of course, even the weakest of reasons given by Unicode becomes a strong reason (in general), just by virtue of being a Unicode Consortium recommendation. Whether it is appropriate for Emacs is another story.