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: How to opt out of curly-quote spamming altogether? Date: Mon, 24 Aug 2015 14:44:19 -0700 (PDT) Message-ID: References: > <834mjoha4r.fsf@gnu.org>> <87wpwkr0se.fsf@fencepost.gnu.org> 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 1440452685 11987 80.91.229.3 (24 Aug 2015 21:44:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Aug 2015 21:44:45 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 23:44:33 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 1ZTzXd-0000oV-D9 for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 23:44:33 +0200 Original-Received: from localhost ([::1]:56894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTzXc-0001Il-TA for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 17:44:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTzXY-0001IK-Tv for emacs-devel@gnu.org; Mon, 24 Aug 2015 17:44:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTzXX-0006yu-Au for emacs-devel@gnu.org; Mon, 24 Aug 2015 17:44:28 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTzXT-0006tV-7N; Mon, 24 Aug 2015 17:44:23 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7OLiLKT019282 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Aug 2015 21:44:22 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7OLiLkP004254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2015 21:44:21 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7OLiKUl013847; Mon, 24 Aug 2015 21:44:21 GMT In-Reply-To: <87wpwkr0se.fsf@fencepost.gnu.org> 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: 141.146.126.69 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:189133 Archived-At: > > Typically, presentation is a separate layer or process, and the > > same structure/content can be, by choice, presented in different > > ways (for different media, among other things). Inline code is > > typically presented using a fixed-width font, such as Courier, as > > opposed to ordinary text, which is typically presented using a > > proportional font. Glossary terms might be presented using bold > > or colored text, perhaps linked to a glossary entry. And so on. > > > > Anyone used to LaTeX or Tex is used to this separation, for > > example. >=20 > That's an interesting statement since plain TeX does not in any > manner provide semantic commands (it switches to a typewriter font when > using verbatim but the reason for that is quite banally that normal text > fonts are not able to print all ASCII characters as they use, say, text > quotes instead of ` and ' characters and some other, more glaring > substitutions). >=20 > Plain TeX does not even have an \em command for emphasizing things. > You need to decide yourself whether to use italics or boldface or > underlining or whatever. Sorry, I should have stuck with LaTeX as the example. It is LaTeX that I am (used to be, many moon ago) familiar with (as a user only). > LaTeX tries to be a bit more semantic, but the sort of differentiation > that Texinfo requires would require loading quite a number of non- > core packages. I didn't mean to suggest that we should use LaTeX (or Tex) - I hadn't considered that. I meant it only as an example, which I thought some people here might be familiar with, of separation of presentation from structure. A better example is XML-based doc. The structure is what it is, and you can render/present it in any number of ways. Likewise, HTML. > > I'm surprised if Texinfo/makeinfo does not provide for it - if an > > inline code snippet or key binding necessarily ends up with a > > presentation that is identical to ordinary text quoting (curly > > quotes, whether single or double). >=20 > Texinfo is primarily semantic markup. Various backends decide how > to typeset things. That's what I thought. And makeinfo is what creates the Info presentation we use. But I have only a vague idea of these things. > In its text mode, plain TeX as well as texinfo.tex convert ` and ' > characters into proper English symmetric quote marks (the respective > default _text_ fonts do not have a straight quote mark or a backquote > in their corresponding character slots). =20 OK, but that is not really the point here. The point is that the pre-presentation way we represent inline code (or URLs or emphasis or whatever structural/semantic elements) would/should ideally not be ` and ' (or curly quotes, a fortiori). Why? For the reason that Paul and others (I think) and I have given: you can't tell when ` and ' are used as markup (for structure) vs representing just themselves as chars. In most doc contexts, some kind of nonambiguous element or markup is used to identify its argument text as of a particular kind (e.g. code). But in Emacs, it is useful to have the representation of the structure be something that users can directly search etc. And it is useful if it can be readable enough to serve more or less for presentation. IOW, any presentation-layer transformation should be kept small/minor, to be able to take advantage of Emacs's ability to manipulate the plain-text input (structure/content layer). IOW, if possible, we don't really want to be looking at, searching, etc., XML elements or similar. And in that context, I personally think that `...' is a reasonable (nearly brilliant) compromise. We could throw some presentation on top of it - I'm not against that. But what we should not do, IMO, is either (a) just replace it by curly-quote chars or (b) render it, as presentation, using curly-quote chars. (a) is because of the PITA of typing etc. such chars, but this is a minor problem compared with (b), I think. (b) is important, to me, because curly quotes are used for ordinary text quoting. Any char should be allowed to represent itself. The problems with ` and ' doing that apply also to curly quotes. And curly quotes also have a day job of quoting ordinary text, unlike ` and '. I would rather have us use, say, highlighting, or a different font, to set off such pieces of text (e.g. inline code), than to show them as if they were ordinary quoted text. But then, if we rendered inline code, URLs etc. by highlighting the text or using a different font, how to search for or within or outside such zones of text? That could be implemented. I have code that lets you search within or outside of zones of text that have particular text properties, for example, or are delimited using buffer positions (e.g. markers). And the same thing could be done for text zones with a particular font (I have not done that, so far). I'm not saying that we need to do something like this. I'm saying that this is preferable to a rendering/presentation that just muddies the water by using ordinary text quoting (curly quotes). We can do better - but not if we give up at the start and adopt curly quotes as our markup and presentation. Personally, I think that sticking with `...' is a reasonable approach: simple, rarely ambiguous, supple wrt inputting the chars, searching, etc. But fixed-width font for such things, and proportional font for ordinary text, would also be a reasonable presentation. > The proper representation in Unicode is the use of the English > =E2=80=98quote marks=E2=80=99: those are the proper characters for the gl= yphs TeX > and Texinfo use for text fonts in the slots for ` and '. > Consequently, it is quite correct that those are the output for > the preformatted Info pages. See above. It's not about translating ` and '. Imagine that those are not used in the input to start with, i.e., that we used other markup to distinguish inline code, URLs etc. That curly quotes are "proper representations in Unicode" of ` and ' is irrelevant. We should not be asking how to represent ` and ', but how to demark things like inline code fragments in a structural layer and how to present them in a presentation layer. Besides which, the "proper representation" of ` and ' in Unicode is ` and '. They are first-class Unicode citizens.