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: Upcoming loss of usability of Emacs source files and Emacs. Date: Tue, 23 Jun 2015 12:16:46 +0900 Message-ID: <874mlzf71d.fsf@uwakimon.sk.tsukuba.ac.jp> References: <557F3C22.4060909@cs.ucla.edu> <5580D356.4050708@cs.ucla.edu> <87si9qonxb.fsf@gnu.org> <5581C29E.1030101@yandex.ru> <87r3p9fxm2.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2v0fiji.fsf@uwakimon.sk.tsukuba.ac.jp> <20150619090225.GA2743@acm.fritz.box> <87fv5kfrfa.fsf@uwakimon.sk.tsukuba.ac.jp> <83twtzhi9g.fsf@gnu.org> <877fqvfvby.fsf@uwakimon.sk.tsukuba.ac.jp> <83fv5jh8ls.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1435029459 3647 80.91.229.3 (23 Jun 2015 03:17:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jun 2015 03:17:39 +0000 (UTC) Cc: acm@muc.de, eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 23 05:17:31 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 1Z7EiI-0001HT-B0 for ged-emacs-devel@m.gmane.org; Tue, 23 Jun 2015 05:17:30 +0200 Original-Received: from localhost ([::1]:43018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7EiH-0006AA-Fv for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 23:17:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Ehm-00063N-83 for emacs-devel@gnu.org; Mon, 22 Jun 2015 23:16:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7Ehk-00063Q-Dv for emacs-devel@gnu.org; Mon, 22 Jun 2015 23:16:58 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:36164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Ehg-00061R-8e; Mon, 22 Jun 2015 23:16:52 -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 2AECE1C385C; Tue, 23 Jun 2015 12:16:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0D9A51A2CA2; Tue, 23 Jun 2015 12:16:47 +0900 (JST) In-Reply-To: <83fv5jh8ls.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:187400 Archived-At: Eli Zaretskii writes: > Try the Windows console some day. I have, and Japanese has worked fine for two decades AFAICR. This includes various quotation marks, which have been accessible from MSIME since Windows 9x at the latest. That might be specific to the Japanese localization though, since you can't do anything without input methods in Japan. So tell me about Hebrew and/or Latin-X? > > That is completely out of context. In the part you quote here, I > > was arguing against a priori judgments for the whole project and > > all its users, without any data except introspection to back them > > up. Not that inconvenience for the opponents was zero to ten > > decimal places. > > I'm saying that the problems might be real even though those who speak > about them have prejudice, and therefore dismissing those problems > just because of that prejudice might be a mistake. I know what you're saying, and I've acknowledged that the problems are real regardless of who is reporting them, several times. Nor did I anywhere imply that prejudice held by a speaker invalidates her statement. That's argumentum ad hominem, a well-known fallacy. I argued that prejudice creates bias, and is invalid as reasoning, and that instead we should seek facts on which to base valid reasoning. So please don't tell me that I'm dismissing your problems while quoting my denial that I was dismissing them and the explanation of what I *was* doing. > > But guess what? AFAICT, the rest of the software world doesn't have > > these problems. People are typing scores of odd characters in email > > to me all the time. And not just Japanese, but good ol' boys and > > girls from the U S of A. How do they manage that, I wonder? > > My guess would be that the mail composing program inserts Unicode > quotes when the user types ASCII quotes. It's not just quotation marks. It's foreign words spelled correctly, ellipses, the occasional math symbol (the lemniscate (infinity) is popular among the more flaky of my correspondents), emoticons, and various other symbols (dice, playing card suit symbols, enclosed characters such as circled numerals). There are too many of them to excuse with "smart quotes"; users are using "input methods" of some sort for these characters that don't exist on their keyboards. Many people *are* willing to pay the cost of inputting these characters; they apparently do like them. OK, so maybe these methods don't exist on the Windows console or are far more annoying than their GUI or email counterparts, and so those characters would be excessively painful to type for you in some contexts. That can surely be fixed (at some cost, eg, using Emacs shell mode, which we already know you strongly oppose paying). On the other hand, Emacs's conservatism in these matters makes Emacs less attractive to new developers. How much? I don't know, you don't know, Alan doesn't know, Paul doesn't know, and RMS doesn't know. Let's try loosening up and find out, no? > > I see benefits to third parties that *you* ignore > > I don't ignore them. You will not see me objecting to these changes > in any of the relevant discussions. You don't bother to mention that you're aware of benefits, or what they are, when you allege that I'm biased against admitting there are costs. As far as I can tell from the words you post, you are indeed opposed to the changes, describing only costs at every turn. I can't know what you're thinking but not posting, sorry. > I just think that we shouldn't dismiss so easily the issues these > changes bring with them. IOW, we should see this issue in its > delicate balance. You're telling *me*? Eli, it's the opponents like RMS, Alan, and Drew who are dismissing all possible benefits without even trying the change for long enough to confirm they can't adjust to the cost. Alan even admits that his opposition is "reactionary".[1] Just like you, I don't have a strong position on the change in question (I like it personally, but am unsure it's good for Emacs "in its delicate balance"). All *I* am advocating is an experiment *in a beta series*, and actually getting data on user preferences *informed by user experience with the change* rather than pushing our biases on them, or polling for user biases. The idea that good user interfaces can be derived exclusively from a priori principles was abandoned by professionals a couple decades ago, except in organizations like Emacs.[2] UI changes need testing in practical use (beta) and tweaking (and sometimes reversion) according to the results. It's certainly true that I've engaged in hyperbole. People (especially the hyperlogical types who hang out here) sometimes *do* change their opinions based on verbal reasoning. User opinions in the absence of experience *do* have a certain amount of validity. Nevertheless, the strong propensity is to resist changing opinions, and for there to be potentially large bias when asking users what they think about *prospective* changes. Shouldn't we take action to get facts to augment reasoning, and to reduce bias in information about user preference? It's also true that I've expressed an *opinion* that the costs to a relative few are small compared to potential benefits for many. Obviously, the opponents disagree about the balance. When opinions differ, shouldn't we go get some actual facts? > It is not practical for me, as it will take too much time, time > that I don't have. "There you go again." You and the opposition focus entirely on the costs *to yourselves*. Rarely do we have much idea of what the benefits of any change we don't propose ourselves might be. Shouldn't we find out, if there are developers who clearly feel there are net benefits and would do the work (including reversion if so decided by the maintainer)? > I prefer that we did these changes right the first time Don't we all? But your apparent belief that others can avoid these "mistakes" without substantial effort from you is unrealistic. I'm sure Paul thought he was doing the right thing at the time. The only way for him to know what you think is the right way is for you to review. You didn't, so you face the cost of making changes now. That's not "wrong", that's just the unpleasant set of alternatives that are actually available to us: review or revise. Every release is an experiment, containing new features that some users, few or many, won't like. Emacs has had a few fiascos among its new features, and tends to be *very* conservative as a result. I propose that it's a lot cheaper to do the experiments when Emacs is still in beta, and so we don't have to be so conservative. Of course it's possible to go too far. What's the appropriate balance? I don't know. I think *this* experiment is a very conservative one. Try it and see, *then* oppose the feature if appropriate. If that works (that is, provides useful information leading to consensus, which might be to keep or to revert the feature), more progressive experiments may be justified. Footnotes: [1] Note: I agree with Alan that having some reactionaries around is a *good* thing, that "somebody has to do it". I don't think we should open up the whole Unicode repertoire to "regularize" syntax at each developer's whim. Each new character introduced needs to be justified. Simply stating that principle isn't enough -- somebody (the "reactionary") is needed to make sure that the discussion takes place. [2] Emacs is an organization of professionals, even if it can't afford to pay them market rates. And it certainly can't afford to pay HCI experts. It just has its reasons for avoiding the experiments needed to get good information about usability of UI changes, and so falls back on "logical thought about the changes". Disclaimer: I believe that those reasons are valid, but they are weaker today than ever before, and the conservatism should be relaxed.