From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Nathan Newsgroups: gmane.emacs.devel Subject: Re: Upcoming loss of usability of Emacs source files and Emacs. Date: Fri, 19 Jun 2015 14:35:06 -0700 Message-ID: References: <20150615142237.GA3517@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="bcaec51d2b809793ba0518e5b28d" X-Trace: ger.gmane.org 1434777324 6498 80.91.229.3 (20 Jun 2015 05:15:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Jun 2015 05:15:24 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 20 07:15:15 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 1Z6B7a-0003DC-3p for ged-emacs-devel@m.gmane.org; Sat, 20 Jun 2015 07:15:14 +0200 Original-Received: from localhost ([::1]:60719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6B7Z-000597-Dd for ged-emacs-devel@m.gmane.org; Sat, 20 Jun 2015 01:15:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z64Bx-0007Cs-Ht for emacs-devel@gnu.org; Fri, 19 Jun 2015 17:51:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z64Bt-0006cR-EM for emacs-devel@gnu.org; Fri, 19 Jun 2015 17:51:17 -0400 Original-Received: from mail-bn1bon0075.outbound.protection.outlook.com ([157.56.111.75]:39696 helo=na01-bn1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z64Bt-0006bu-7r for emacs-devel@gnu.org; Fri, 19 Jun 2015 17:51:13 -0400 Authentication-Results: gnu.org; dkim=none (message not signed) header.d=none; Original-Received: from mail-vn0-f44.google.com (209.85.216.44) by BLUPR04MB561.namprd04.prod.outlook.com (10.141.29.149) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 19 Jun 2015 21:35:08 +0000 Original-Received: by vnbg190 with SMTP id g190so767592vnb.6 for ; Fri, 19 Jun 2015 14:35:06 -0700 (PDT) X-Received: by 10.52.32.34 with SMTP id f2mr14575985vdi.11.1434749706405; Fri, 19 Jun 2015 14:35:06 -0700 (PDT) Original-Received: by 10.52.166.129 with HTTP; Fri, 19 Jun 2015 14:35:06 -0700 (PDT) In-Reply-To: <20150615142237.GA3517@acm.fritz.box> X-Originating-IP: [209.85.216.44] X-ClientProxiedBy: BLUPR0401CA0042.namprd04.prod.outlook.com (25.162.114.180) To BLUPR04MB561.namprd04.prod.outlook.com (10.141.29.149) X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB561; 2:y3dElzN2uoGLfFiZ7qFqRce90+fVmFA0HgRKLHARJP/wuZ4ZmbxprbpLvYVhnNM9; 3:pjxsUao2gLQh4nGtYsay/gCF4OuuWrLQCEDJqgaXbQYfsMhsjgq73QkyCUyQ1CFRWnpwUYMmDcTxTJPE5JtMui6HR7LxNx2mUk9MoZQ+ecrHW6Xm24mMpbMbadXmdO9lNxQ7dRHnz/5CAU5QpmQjhg==; 20:bGt7PLBEd9pcPn8gFYcPMqYzpL2xYCMgOaaL8y5YCUOR1UMxvtvaznvHTFeh1idLp31B8g1gS4vzYH+ATL49ToehdvLRa+j2doQo9YrTvNk4VUWzN8BzEzyfPUk8FsH3Nm9D6SFmiecZWaWqcT5L202Mabp780fgA0X50uuvbGiK0/I9cOHjy8i1J24sIxjTETOS2Zt59k3qihjYDTiBgUSSwXjahtzFAXJ+hL1kYMMYVI6dMMJldRB7LyBCYqbgia+zQZ/1eFSXXjDqT1n1o6MAqU1Jb7triIskaxa3JFVBBImvX1tk7zgpMV4qH9LdrhvrZSwQopKyScUlPAooUDbzglW0G+9u/0Emkgq26qOwIrHbxGJPVztqCNmskHreOgsmS9bpyMka2Jkl9dT617+5Rh6CrB6vO8M7bH7q0HI=; 4:DJyK7hd0rjCjbae2szwINQoSiC9opxAcoto/7ASLpXNZM58GxuNnwV6ClVhLmY6iCT3uYxiWr8qqP/6O8g5K2veLjPPInQ99mjyjAhBQLESBIY1rpsptg9q0KMFO0/eYQLvZGNl+5qR38wvC4AHqxeDhvDCkAmRYn5sqp+inh7SQdnF2EcyikwCTBL X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR04MB561; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR04MB561; BCL:0; PCL:0; RULEID:; SRVR:BLUPR04MB561; X-Forefront-PRVS: 0612E553B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(377454003)(51704005)(24454002)(110136002)(19580395003)(19580405001)(87976001)(5001960100002)(86362001)(89122001)(63696999)(55446002)(66066001)(61726006)(76176999)(61266001)(50986999)(54356999)(84326002)(512874002)(2950100001)(42186005)(77156002)(62966003)(122386002)(450100001)(75432002)(122856001)(40100003)(88552001)(46102003)(92566002)(189998001)(59536001)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR04MB561; H:mail-vn0-f44.google.com; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB561; 23:MEBFDvVWSrHCL8vlftHStKb6h3x7RVooWdUef5XBpUCXPyoUm/DHiAtuoWnD5/Bjw9zkfq4mWIXoIWVtYEwDOwtkQQfZGBWWHBy/swWp6fD3gUtOOY9l2QRc5Qxf/tip9wE7z1cAL1Zs2bE+HjeLlGKh01411B6PMJi5WrDm/cLRRKte9ZTV3R3bfWocw+vnG3rYQMX56/8oFcE9JU49CYyMB6XHYY9ZUmkyNgvf9hFfdYu6L6CbrV8e330b+nSN1WNRMofOpGFm0oamTrkDydJgyZckU+bnczSb7P+kz4E9DOJovuRzD00al+WrNoumLRZXSqN217e0bGfkq5SFIEed4RmyXYwQ4WGZw4pSQGphG17/VmGfuI5d0GYQe+bURWbM5rF38h6F3hc6BY1+3AgL//4XkYHnX6mV61KU0jk8ljxvCds0G1om3N5xAweXtnA6JxUMMAP/JgJ9fK9K5KdpPVei5LyBtoanCQQ03IHvM7o0QEyWIhxTXHmgeGr7OxjRrzr2E8sp4HYtpvPFsIvq5x3o/y0gR+9nvnRn077o9PaQ7I2cxl76UatQDmS9QNitkOVGRkV15Zd3wGvSBjEpAzJ1obSffZEf6eKDPRLbNbOwIkncRIy0EmDJdNt1uoBXR8YJhlCXliOsge4dE7nfEu76x1k5nDUjAzEVPXtAZHQDU1K98jY5uhyVIw8gUr1X32erluoCP54LtdVpfmAFiwbqUKwr+PwQ/k31n50pD6OAF7Z7mJ2LVX1BfnWGj0gJveX+UzMiPOiGYJEXP0rwlDa0 AeTIfU1zLcs7S2hSp6d92P+wspnFX89o5ve7r9HbWhZdnfk X-Microsoft-Exchange-Diagnostics: 1; BLUPR04MB561; 5:5z2EzMzsTGdB5DTFJ+mOZSs9qV8sObURhCcuYApNp4wj3qAbOpQFGlqcQ56+mQeHOb4Yed36F+1jBHOEAQ1WDLTZVs/x78CQl7SpZCfQEFz+yf1SS+mBHXXniYQHOkgYPjfnTGPQkFvqKpEgFvTGiw==; 24:UHuS1yRzfFk/YCylsd5fjjJx8zwa/owI/IDFxSFCbX3PPM/cZ8x76MJdrLKonIh0cSJ+gqqfmyIZCjoI5Wmp+5OjPx8g3jccEY6hPNbqog8=; 20:lh15KL+xDT9VMyw8nFpzizWC9RDp1HpsJUsWii2iUXy1I+7I7D+uN0CAJGrJ6hx0/VqXTw2FExlt8OhFs8QanQ== X-OriginatorOrg: alumni.uidaho.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2015 21:35:08.9023 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR04MB561 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (barebone) [generic] [fuzzy] X-Received-From: 157.56.111.75 X-Mailman-Approved-At: Sat, 20 Jun 2015 01:14:55 -0400 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:187334 Archived-At: --bcaec51d2b809793ba0518e5b28d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello gentle emacs-devel members, I am a boring person with a bog standard US keyboard, who uses emacs extremely regularly, and I would prefer that the character set used be 7-bit ASCII, for the single and solitary reason that I would prefer to type out characters rather than hunt them down on the Internet or some font program to copy & paste the character into my emacs. The vast majority of the programs I write and the files I work with are 7-bit ASCII. This is, indeed, typical of the organizations I have worked with. Non-ASCII rendering was confined to .po files and other i18n situations. It is perhaps unfortunate and certainly an accident of history, but my keyboard is limited, and is as limited in its expression as my ancient IBM PS/2 keyboard. It would satisfy me if I could have a variable *render-in-7-bit* that could be set to T, and I could continue on my placid and slightly antique way, with an aesthetic renderer taking over when *render-in-7-bit* is set to NIL= . On Mon, Jun 15, 2015 at 7:22 AM, Alan Mackenzie wrote: > > Hello, Emacs. > > First, some definitions. > > A @dfn{working character} is a character you use in everyday life - you > can type it easily on your keyboard for self-insert-command, and it is > displayed clearly and unambiguously on your screen. As Emacs developers, > our working characters are basically ASCII, though each of us has his own > characters (e.g. =C3=A4, =C3=B6, =C3=BC, =C3=9F for me) which count as "p= rivate" working > characters. > > By contrast, a @dfn{display character}, or @dfn{non-working character} is > a character which isn't a working character. To insert it into a buffer, > you need to type its numeric code, or use (and remember) a C-x 8 ... > binding, or some other clumsy workaround. It might or might not get > properly displayed on your screen. > > Traditionally, Emacs sources have been written exclusively in working > characters (with the essential exception of some characters which stand > for themselves, such as some non-ASCII punctuation symbols used in > `sentence-end'). This makes editing our source files optimally > efficient. > > Recently, there has been a move, primarily by Paul, to introduce > non-working characters (specifically, LEFT/RIGHT SINGLE QUOTATION MARKs, > or (less shoutily) "curly quotes") into our sources and *Help* buffers, > not just marginally, but routinely into all our doc strings and error > strings. > > Paul and I have had an extensive discussion on many of the issues this > raises, in the thread for bug #20707. I am against these changes for > several reasons: basically, they will make our sources more difficult to > read and edit. I am not even sure of the motivation for the changes, > though I think it is mainly that some people find the appearance of 0x60 > and 0x27 as quote marks unaesthetic in some display environments. > > My main objection is there is no option to turn this new "feature" off. > Some users are going to dislike these changes, possible dislike them a > lot, but we are going to be forcing the curly quotes on them. This is > going to create much dissatisfaction. For comparison, the fringe was a > new feature in Emacs-21 which had no way of being disabled. Many users > hated it, and were up in arms about it until this was fixed in Emacs-22. > > My view is that the curly quotes should not replace 0x60 and 0x27 in our > sources, but that the option to display them as curly quotes should be > made available to those that want it. > > As far as I am aware, there has been no poll to gather and analyse the > views of Emacs developers on these changes, much less one for Emacs > users. This is a Bad Thing. > > What do people think? > > -- > Alan Mackenzie (Nuremberg, Germany). > > --bcaec51d2b809793ba0518e5b28d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello gentle emacs-devel members,

I am a boring person with a bog standard US keyboard, who uses emacs ex= tremely regularly, and I would prefer that the character set used be 7-bit = ASCII, for the single and solitary reason that I would prefer to type out c= haracters rather than hunt them down on the Internet or some font program t= o copy & paste the character into my emacs. The vast majority of the pr= ograms I write and the files I work with are 7-bit ASCII. This is, indeed, = typical of the organizations I have worked with. Non-ASCII rendering was co= nfined to .po files and other i18n situations.

It is perhaps = unfortunate and certainly an accident of history, but my keyboard is limite= d, and is as limited in its expression as my ancient IBM PS/2 keyboard.=C2= =A0

It would satisfy me if I could have a variable *render-in= -7-bit* that could be set to T, and I could continue on my placid and sligh= tly antique way, with an aesthetic renderer taking over when *render-in-7-b= it* is set to NIL.


On Mon, Jun 15, 2015 at 7:2= 2 AM, Alan Mackenzie <acm@muc.de> wrote:

Hello, Emacs.

First, some definitions.

A @dfn{working character} is a character you use in everyday life - you
can type it easily on your keyboard for self-insert-command, and it is
displayed clearly and unambiguously on your screen.=C2=A0 As Emacs develope= rs,
our working characters are basically ASCII, though each of us has his own characters (e.g. =C3=A4, =C3=B6, =C3=BC, =C3=9F for me) which count as &quo= t;private" working
characters.

By contrast, a @dfn{display character}, or @dfn{non-working character} is a character which isn't a working character.=C2=A0 To insert it into a = buffer,
you need to type its numeric code, or use (and remember) a C-x 8 ...
binding, or some other clumsy workaround.=C2=A0 It might or might not get properly displayed on your screen.

Traditionally, Emacs sources have been written exclusively in working
characters (with the essential exception of some characters which stand
for themselves, such as some non-ASCII punctuation symbols used in
`sentence-end').=C2=A0 This makes editing our source files optimally efficient.

Recently, there has been a move, primarily by Paul, to introduce
non-working characters (specifically, LEFT/RIGHT SINGLE QUOTATION MARKs, or (less shoutily) "curly quotes") into our sources and *Help* bu= ffers,
not just marginally, but routinely into all our doc strings and error
strings.

Paul and I have had an extensive discussion on many of the issues this
raises, in the thread for bug #20707.=C2=A0 I am against these changes for<= br> several reasons: basically, they will make our sources more difficult to read and edit.=C2=A0 I am not even sure of the motivation for the changes,<= br> though I think it is mainly that some people find the appearance of 0x60 and 0x27 as quote marks unaesthetic in some display environments.

My main objection is there is no option to turn this new "feature"= ; off.
Some users are going to dislike these changes, possible dislike them a
lot, but we are going to be forcing the curly quotes on them.=C2=A0 This is=
going to create much dissatisfaction.=C2=A0 For comparison, the fringe was = a
new feature in Emacs-21 which had no way of being disabled.=C2=A0 Many user= s
hated it, and were up in arms about it until this was fixed in Emacs-22.
My view is that the curly quotes should not replace 0x60 and 0x27 in our sources, but that the option to display them as curly quotes should be
made available to those that want it.

As far as I am aware, there has been no poll to gather and analyse the
views of Emacs developers on these changes, much less one for Emacs
users.=C2=A0 This is a Bad Thing.

What do people think?

--
Alan Mackenzie (Nuremberg, Germany).


--bcaec51d2b809793ba0518e5b28d--