From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors Date: Wed, 10 Jun 2015 13:39:31 +0000 Message-ID: <20150610133931.GA3632@acm.fritz.box> References: <20150606155445.GE3418@acm.fritz.box> <557337CD.60706@cs.ucla.edu> <20150606205023.GA3862@acm.fritz.box> <55738BA9.7050104@cs.ucla.edu> <20150608171804.GA3184@acm.fritz.box> <55768D82.3040509@cs.ucla.edu> <20150609133423.GA3735@acm.fritz.box> <5577516B.9020709@cs.ucla.edu> <20150609224616.GC3735@acm.fritz.box> <557779E9.3050409@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1433943641 12542 80.91.229.3 (10 Jun 2015 13:40:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Jun 2015 13:40:41 +0000 (UTC) Cc: 20707@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 10 15:40:23 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Z2gEs-0003yq-57 for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jun 2015 15:40:18 +0200 Original-Received: from localhost ([::1]:40289 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2gEr-0000dC-F8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jun 2015 09:40:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2gEj-0000bv-Pd for bug-gnu-emacs@gnu.org; Wed, 10 Jun 2015 09:40:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2gEf-0002Bk-OI for bug-gnu-emacs@gnu.org; Wed, 10 Jun 2015 09:40:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2gEf-0002Av-M0 for bug-gnu-emacs@gnu.org; Wed, 10 Jun 2015 09:40:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z2gEe-0003HR-TH for bug-gnu-emacs@gnu.org; Wed, 10 Jun 2015 09:40:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jun 2015 13:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20707 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 20707-submit@debbugs.gnu.org id=B20707.143394354812458 (code B ref 20707); Wed, 10 Jun 2015 13:40:04 +0000 Original-Received: (at 20707) by debbugs.gnu.org; 10 Jun 2015 13:39:08 +0000 Original-Received: from localhost ([127.0.0.1]:46882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z2gDi-0003Er-Ue for submit@debbugs.gnu.org; Wed, 10 Jun 2015 09:39:07 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:20116) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z2gDe-0003Ea-Ln for 20707@debbugs.gnu.org; Wed, 10 Jun 2015 09:39:04 -0400 Original-Received: (qmail 78229 invoked by uid 3782); 10 Jun 2015 13:39:01 -0000 Original-Received: from acm.muc.de (p548A5390.dip0.t-ipconnect.de [84.138.83.144]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 10 Jun 2015 15:39:00 +0200 Original-Received: (qmail 4057 invoked by uid 1000); 10 Jun 2015 13:39:31 -0000 Content-Disposition: inline In-Reply-To: <557779E9.3050409@cs.ucla.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103787 Archived-At: Hello again, Paul. On Tue, Jun 09, 2015 at 04:42:33PM -0700, Paul Eggert wrote: > Alan Mackenzie wrote: > >> Curved single quotes are also "working" characters, both in Emacs > >> >(master branch) and in Texinfo (latest stable version). > > They're not > It sounds like your definition of "working" differs from what I thought it > meant. I had thought an informal definition with examples would suffice. Seems not. How about a "working character" being "a character it's easy to work with"? That would involve it being easy to type on some standard keyboard, and being displayable on "all" standard display environments. > I thought you were using "working" to mean that a character has a > special function in Emacs or in the file that one is editing. But as I > understand it now, by "working" you mean that it's a character on your keyboard. > If so, then yes, you're right, curved single quotes are typically not > "working" characters. But I fail to see the significance of this point. Imagine a keyboard where _all_ characters had to be input by giving their ASCII (or unicode) code. That would be hellish, and completely unusable by any normal person. Now scale that back a bit, so that only _some_ characters need to be input by code. That's bad if you use these characters. That's like the situation you want to create. You want to promote difficult-to-type and problematic-to-display characters to the status of standard "working characters". This will make Emacs less usable. > For example, the newline character is not a "working" character on my > keyboard, but that doesn't mean we should exclude newlines from our > source files. Newline isn't a "character" in the sense meant. It does not appear in any font. It is more a command than a character. I admit you could repeatedly pick holes in any informal definition of "working character" I give, until we end up with a rigorous, and bearly readable, definition. That wouldn't be a good use of time for either of us. > >> >It's true that not every keyboard can generate them in every Emacs > >> >context with just a single keypress, .... > >> >but that's also true for many ASCII characters. > > Also untrue, for the large class of keyboards which are based on the > > Latin alphabet. > I have such a keyboard, and when I type Return, Emacs doesn't put a carriage > return into a typical buffer; it does something else. Or when I type the \ key > in a Lisp string, Emacs doesn't put a \ into the string; it does something else. > Or when I type a space character when searching, Emacs doesn't search for a > space; it does something else. In all these cases, if I really want to get > exactly the ASCII character in question, I have to do something other than type > a key labeled by that character. And my point was that this is something that > many ASCII characters have in common with curved quotes. That's a total diversion. In normal typing, the characters embossed on your physical keys are what you see when you type them. I put it to you that you don't have any of the four curly quote characters embossed on any key on your keyboard, and you have no easy way to type them. I.e. they're "display characters" even for you. You have no problem whatsoever typing \ or space. I have a feeling you're intending to argue for making the use of curly quotes in our Lisp files standard. That would be a backward step for usability. Anyway, here's another idea for making curly quotes in lisp code optional: an escaped 0x27 or 0x60 in a string should be translated by the reader to the appropriate ASCII or curly quote, depending on the user's configuration. So a doc string might contain this: \`foo-bar\' , and would become ?foo-bar? on your system and `foo-bar' on mine. That way, the quotes are still visible in the source as quotes, and the extra space taken up is minimal, in fact no more than when a " needs to be escaped. It would also be fully backward compatible with earlier Emacsen. A slight disadvantage would be that users would have to compile the lisp sources when building a new Emacs. There are fewer than 61004 occurrences of `...' in our sources. This could make the extra effort involved in adapting the C source to handle --with-curly-quotes worthwhile. > > the standard default Linux console font, default8x16 > It's news to me that this is the standard default Linux console font. It's not > available in Ubuntu or in Fedora, which are popular GNU/Linux distributions. It's a first class member of the set of fonts distributed in the source from http://freshmeat.net/projects/kbd/. It's certainly the default in Gentoo, quite likely in other distros, too. > Perhaps it's something used at a low level while booting? That would make > sense, if it uses the same encoding that the IBM PC used back in 1981. Anyway, > it doesn't seem to be of much practical relevance to this thread. Getting back on topic, we agreed yesterday that things should "just work", and that users should not have to fiddle around with fonts. If you make this change, then fiddling around with fonts is precisely what some users are going to have to do. Again, I think the only justification for the change you've given is that you personally don't like the look of 0x60 and 0x27 used as quote characters. Is that really sufficient justification for the loss of usability we would all face, and the problems with fonts which a subset of users would be faced with? With my new idea above for `...' in lisp files, how about reconsidering my "Q" C macro from a few days ago? -- Alan Mackenzie (Nuremberg, Germany).