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: Upcoming loss of usability of Emacs source files and Emacs. Date: Sun, 28 Jun 2015 16:05:06 -0700 (PDT) Message-ID: <75f2fe0f-f15e-4af8-b9ae-0ddc9231c9ab@default> References: <20150615142237.GA3517@acm.fritz.box> <87y4jkhqh5.fsf@uwakimon.sk.tsukuba.ac.jp> <557F3C22.4060909@cs.ucla.edu> <5580D356.4050708@cs.ucla.edu> <87si9qonxb.fsf@gnu.org> <5581C29E.1030101@yandex.ru> <558D6A3D.1070706@yandex.ru> <877fqnzpno.fsf@gnu.org> <5590493C.8000007@yandex.ru> <87381bzife.fsf@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 1435532743 26271 80.91.229.3 (28 Jun 2015 23:05:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 23:05:43 +0000 (UTC) Cc: Paul Eggert , rms@gnu.org, emacs-devel@gnu.org, Stefan Monnier , acm@muc.de, stephen@xemacs.org To: Tassilo Horn , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 29 01:05:30 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 1Z9Ldh-0007AD-Oh for ged-emacs-devel@m.gmane.org; Mon, 29 Jun 2015 01:05:30 +0200 Original-Received: from localhost ([::1]:40063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Ldg-0005fx-IC for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2015 19:05:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Ldb-0005fo-Qz for emacs-devel@gnu.org; Sun, 28 Jun 2015 19:05:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9LdY-00053z-0j for emacs-devel@gnu.org; Sun, 28 Jun 2015 19:05:23 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:49184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9LdX-00053v-QM; Sun, 28 Jun 2015 19:05:19 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5SN59Vn014087 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Jun 2015 23:05:10 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t5SN570Q032505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 28 Jun 2015 23:05:07 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t5SN553B000453; Sun, 28 Jun 2015 23:05:06 GMT In-Reply-To: <87381bzife.fsf@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: userv0021.oracle.com [156.151.31.71] 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:187629 Archived-At: > That wasn't really meant as a suggestion. I just wanted to ask why > not use some extremely rare paired characters if unambiguity is the > main point and we have some convenient input method anyhow. That > simply typing a key which has the exact letter on it is even better > is obvious. FWIW, a week or so ago I almost posed the same rhetorical question. I was going to use this pair as an example [1]: =E2=97=84foobar=E2=96=BA BLACK (LEFT|RIGHT)-POINTING POINTER Here it is, used for sexps and key descriptions we might show in Lisp docs/help: =E2=97=84foobar=E2=96=BA =3D `foobar' =E2=97=84"foobar toto"=E2=96=BA =3D `"foobar toto"' =E2=97=84(foobar toto 42)=E2=96=BA =3D `(foobar toto 42)' =E2=97=84`(setq foo ',(bar t))=E2=96=BA =3D ``(setq foo ',(bar t))' =E2=97=84M-x apropos-char=E2=96=BA =3D `M-x apropos-char' =E2=97=84C-x C-c=E2=96=BA =3D `C-x C-c' Here are the same sexps shown with curly quotes: =E2=80=98foobar=E2=80=99 =3D `foobar' =E2=80=98"foobar toto"=E2=80=99 =3D `"foobar toto"' =E2=80=98(foobar toto 42)=E2=80=99 =3D `(foobar toto 42)' =E2=80=98`(setq foo ',(bar t))=E2=80=99 =3D ``(setq foo ',(bar t))' =E2=80=98M-x apropos-char=E2=80=99 =3D `M-x apropos-char' =E2=80=98C-x C-c=E2=80=99 =3D `C-x C-c' Tassilo's point here, I think, and at least my point here, is that this is *not at all about quotation* in the usual sense. There is no reason to use quotation marks of any kind, which can mess with their ordinary use as, well, er, um, quotation marks. Those who make claims to the effect that 99.999% of the world uses curly quotes miss the point entirely, IMHO. Of course they do! (Well, maybe not five 9s.) And so do I. But they use them for text *quotation*. That's not what we use `...' for. We use it to set off code phrases from surrounding text that talks about them. It is our equivalent of markup such as ... and .... Yes, of course, *any* mention instead of use is a form of quotation in the larger, logical sense. Quoting means pushing up a metalanguage level, and vice versa. But that's really beside the point here. We have a context where we want to distinguish code from text, including from text quotations. Emacs is, among other things, a general text editor. And we would like, if possible, the external form to be the same as the internal form. If we can avoid it, we would prefer not to have ... or similar be what is written in a file and have that just be rendered using highlighting or a special font - which is the typical treatment. We could live with that approach, no doubt, but it is not what we would prefer. Why? Because we want to act on the internal form directly, including interactively, in ways that other contexts do not, or that do so only inelegantly, clumsily, or in a restricted way. We are spoiled, I guess, having had the simplicity of Lisp syntax and simple `...' sexp mention for decades now. It's true that you can use a good XML editor to both render XML-based documents in a formatted way and let you search for text that is within (or without) ... elements. But the UIs they provide, including for operations such as search-&-replace and other modifications, are far too clunky and limited for what we do. Can we do what others do, having a different internal representation from what gets rendered? Of course. And some are arguing that that's the approach to take wrt curly quotes, to paper over some of the warts. Do we want to have to fiddle with two different levels that way: internal vs rendered representations? Of course not, if we can reasonably avoid it. Emacs is about Lisp for a reason. And Lisp is about representing programs and data the same way - for a reason. If we can avoid such a translation and flipping between representations, we would prefer it in general - direct action, WYSIWYG. So why do I say (as Tassilo also suggests, I think) that =E2=97=84foobar=E2=96=BA is only a *rhetorical* suggestion? Why don't I really propose such a solution? (And why didn't I bother to mention it a week ago?) For all of the Emacsy reasons people have so far given that explain why curly quotes are a bad idea: trouble inserting, searching, etc. That is, for all of the _other_ reasons, besides the reason that this is not about quotation. What we should look for is both (1) a mirror pair of chars that is not confusable with other uses of the same and (2) a pair of chars that is simple to insert, search, etc. - in general, simple to use in a rudimentary, plain-text (perhaps even ASCII) context. Criterion #1 rules out pairs such as curly quotes and guillemets of all stripes, as well as [], (), {}, <> etc. Criterion #2 rules out most non-ASCII Unicode chars. (There is a third criterion that makes life easier: a pair of *different* chars, not just using the same char twice: '...', `...`, |...|, \...\, /.../, etc. This is maybe not essential, but it is handy.) These two criteria work against each other to some extent. To fit #1 we want a pair that is *rarely used* in typical contexts, including documentation and other ordinary text contexts (which make use of quotation). But to fit #2 we want a pair that must not be rare, because rare chars are not easily typed, searched for, and otherwise used in even a rudimentary plain-text context. Maybe someone has a truly brilliant idea for this? Note that we are in this dilemma, with these opposing criteria, precisely because we have (till now) opted to not use two different representations: internal and external. Sacrificing that simplicity and going to two representations is one way to go, I guess, but it is not one I favor. `...' is the most brilliant idea I've seen so far for this. Satisifies all of the criteria. Simple; straightforward; just works. It ain't broke, and we shouldn't fix it. But it has *one* strike against it: a few people find it =E2=80=9Cugly=E2=80=9D, =E2=80=9Fugly=E2=80=9D, "ugly", =E2=80=98ugly=E2=80= =99, =E2=80=9Fugly=E2=80=9E, =E3=80=9Dugly=E3=80=9E, =E2=9D=9Dugly=E2=9D=9E= , =E2=9D=9Bugly=E2=9D=9C, =C2=ABugly=C2=BB ! Some of us don't find it so, but yes, beauty is in the eye of the beholder. Why someone's beauty concerns should trump usefulness I don't know. Mais on n'arrete pas le progres... --- [1] Believe it or not, I scanned all of the Unicode chars for a good example - a pair that works in terms of char width (at least for the fonts I tried), one that has no particular other use with which this use might be confused, and one that is not easily confused with other pairs (e.g. various forms of brackets).