From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 9ce1d38: Use curved quotes in core elisp diagnostics Date: Tue, 18 Aug 2015 12:55:37 +0900 Message-ID: <87io8dw8qu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150816160149.9416.80132@vcs.savannah.gnu.org> <55D1043C.3030909@yandex.ru> <55D15899.2070105@cs.ucla.edu> <20150817121513.GA2634@acm.fritz.box> <55D21191.8070202@cs.ucla.edu> <55D2265B.5030109@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1439890057 28135 80.91.229.3 (18 Aug 2015 09:27:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Aug 2015 09:27:37 +0000 (UTC) Cc: Paul Eggert , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 18 11:27:27 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 1ZRdB0-0003kK-Uz for ged-emacs-devel@m.gmane.org; Tue, 18 Aug 2015 11:27:27 +0200 Original-Received: from localhost ([::1]:55349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRdB0-0007pP-5W for ged-emacs-devel@m.gmane.org; Tue, 18 Aug 2015 05:27:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRY05-00024K-Kn for emacs-devel@gnu.org; Mon, 17 Aug 2015 23:55:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZRY00-0003S2-Kx for emacs-devel@gnu.org; Mon, 17 Aug 2015 23:55:49 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:37525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRY00-0003Ps-Bf for emacs-devel@gnu.org; Mon, 17 Aug 2015 23:55:44 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CCC411C38D1; Tue, 18 Aug 2015 12:55:38 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E36C311EF83; Tue, 18 Aug 2015 12:55:37 +0900 (JST) In-Reply-To: <55D2265B.5030109@yandex.ru> X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (barebone) [generic] [fuzzy] X-Received-From: 130.158.97.161 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:188865 Archived-At: Dmitry Gutov writes: > Unicode characters are good, we should use them in text, but not in the > basic syntax of the language or its environment. Oh, so you want a computer language where characters are used only in strings? Good trick, that. Seriously, now that we do have Unicode, and good implementations of it (although Emacs's isn't complete yet, it's certainly usable), there's really no excuse for _a priori_ restricting the character set used in a computer language. Yes, discipline is necessary: the *size* of the character set (aside from identifier constituents) should not be expanded without good reason. But which characters are used shouldn't be decided on the basis of historically limited charsets. They should be chosen because they are appropriate to their syntactic roles. Backward compatibility is important. The old-timers have a point -- the ASCII workarounds we've used for decades still work, and adding new synonyms or changing the syntax to substitute more accurate versions is costly to experienced users and developers. I personally agree with Paul -- the appropriate place to experiment with this kind of thing is with string conventions that don't change the meaning of Lisp programs per se, although they do affect parsing of output and editing Lisp programs. It's all about eating your own dogfood. But although I like these changes, they are hardly a no-brainer. On the other hand, not liking input methods? That's not admissible: Emacs is the world's biggest, most complex input method, and that is its primary mission. If you can handle Emacs, you can learn a couple dozen additional keystroke combinations to input new syntactically significant characters (and surely the extended repertoire will include only a few such for many years -- "a couple dozen" is a generous concession to reactionary fears).