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: Wed, 19 Aug 2015 15:31:47 +0900 Message-ID: <87bne3wzzg.fsf@uwakimon.sk.tsukuba.ac.jp> References: <55D1043C.3030909@yandex.ru> <55D15899.2070105@cs.ucla.edu> <20150817121513.GA2634@acm.fritz.box> <55D21191.8070202@cs.ucla.edu> <20150817173551.GB2634@acm.fritz.box> <55D29EA6.2020009@cs.ucla.edu> <20150818103921.GA2262@acm.fritz.box> <55D36132.1020900@cs.ucla.edu> <20150818171715.GD2262@acm.fritz.box> <55D3869E.30302@cs.ucla.edu> <20150818204211.GF2262@acm.fritz.box> <55D3A641.7040409@cs.ucla.edu> <87bne4fc7s.fsf@wanadoo.es> 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 1439965935 12513 80.91.229.3 (19 Aug 2015 06:32:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 06:32:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 19 08:32:00 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 1ZRwul-0005oE-Ri for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 08:32:00 +0200 Original-Received: from localhost ([::1]:60657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRwuk-0000Qc-NU for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 02:31:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRwug-0000PZ-Hn for emacs-devel@gnu.org; Wed, 19 Aug 2015 02:31:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZRwud-0006fn-8r for emacs-devel@gnu.org; Wed, 19 Aug 2015 02:31:54 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:43467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRwuc-0006de-OM for emacs-devel@gnu.org; Wed, 19 Aug 2015 02:31:51 -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 A65431C39B1; Wed, 19 Aug 2015 15:31:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 85ED911EF83; Wed, 19 Aug 2015 15:31:47 +0900 (JST) In-Reply-To: <87bne4fc7s.fsf@wanadoo.es> 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:188933 Archived-At: =C3=93scar Fuentes writes: > Dmitry suggests this, and his comment about modern markup languages > restricting themselves to ASCII is something to think about. Not really. No chicken developed from that egg because there was no chicken to lay the egg in the first place. By and large programmers' environments are deficient in respect of input methods, especially in the U.S., and until a few years ago solid multilingual Unicode environments weren't really available (and still aren't on Windows, if I understand Eli's descriptions correctly). So programmers (who design markup languages) restrict themselves to ASCII-based markup. It's only become reasonable to think about going beyond ASCII in the last 5 years or so (if you want to maintain fairly general appeal). And there's the counterexample of Xe[La]TeX, which in fact developed for Mac, the most complete Unicode implementation available at the time -- a single anecdote, but very suggestive IMHO. Emacs is the perfect environment to experiment with *discoverable* *multilingual* input methods. AFAIK, they don't exist yet, *anywhere*. Apple is going backwards, even. Microsoft doesn't have them, either. The proprietary technology is quite good -- within the context of monolingual environments (which is where the money is, even in Europe the number of companies where individuals need multilingual environments is limited). But they require effort for neophytes to learn, and are less than useful for "inputting 'exotic' characters. As far as I can tell, there's nothing better out there for free software, either -- we're now on our fourth or fifth generation of new input management frameworks for GNOME and/or KDE, and *still* the most frequent n00b question on the Tokyo Linux Users Group[sic] is "I just upgraded MyDistro and now I can't input Japanese in WhateverOffice". My Chinese students and Buddhist scholar friends all use Macs because it's very easy to switch among input methods (Chinese, Japanese, and Sanskrit are radically different -- it's sort of possible to share an input method between Chinese and Japanese, but it's very painful). But all of these methods are monolingual, and must be learned separately (or "taught", as most "learn" the user's habits, changing priorities in the dictionaries and storing common sequences of words for "predictive translation"). Emacs at least has Quail, giving language flexibility as good or better than Apple, although the input methods themselves are static, so aren't as user-friendly as the proprietary ones that "learn" the users' habits. And (one small step for Emacs, one giant step for mankind) Quail methods are self-documenting (although again discoverability needs to be improved for the purpose of "typing 'exotic' characters"). > I admit that I'm intrigued by your plan about how this change will > initiate an evolution on Emacs input system that will make easier to > type exotic characters (defining "exotic" by "something that it is > infrequent in your daily usage.") By giving people an itch they want to scratch. Most people will just cut'n'paste or add ad hoc keybindings for the characters they need. Some people will do more, and sooner or later one of them will come up with a much better way to do input methods. It's not obvious to me what that will be, and it's probably useless to ask Paul what it will be too. David K pointed out that there are some useful ideas in x-symbol. That might be one place to look. Also, besides input methods, it will likely lead to improvements in other technologies such as searching (adding character classes of "cognates" such as ` and =E2=80=98, for example -- this is useful for repertoires like Japanese which has about a dozen variants on open parenthesis more or less commonly used in text, as well as a pile of numeral variants used for paragraph numbering, and the like). Those opposed to the change will cry YAGNI, and that's true -- if you live in an 8-bit world anyway, you just can't afford that kind of redundancy. But like it or not, the world is now mostly Unicode and that will only increase. Japanese is probably the most perverse character set in existence, but I believe Chinese and Korean also have similar issues of many classes of characters that have redundant functionality, and it shows up in other places (eg, arrows and emoticons). > Maybe describing the specific user-visible improvements that this > change will help to bring into reality would buy you more support. The user-visible improvements have been described and are easily visible to the eye desiring to see them. Tastes just differ here; the people who don't like the change see little to no improvement, and IIUC Drew even considers it a clear step backward aesthetically.