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, 16 Jun 2015 09:50:29 +0900 Message-ID: <87vbeoh3xm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150615142237.GA3517@acm.fritz.box> <87y4jkhqh5.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1434415856 9974 80.91.229.3 (16 Jun 2015 00:50:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Jun 2015 00:50:56 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 16 02:50:46 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 1Z4f5R-00068R-Qe for ged-emacs-devel@m.gmane.org; Tue, 16 Jun 2015 02:50:46 +0200 Original-Received: from localhost ([::1]:37018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4f5Q-0002b5-Iu for ged-emacs-devel@m.gmane.org; Mon, 15 Jun 2015 20:50:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4f5K-0002ao-Nz for emacs-devel@gnu.org; Mon, 15 Jun 2015 20:50:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z4f5F-0000C6-LT for emacs-devel@gnu.org; Mon, 15 Jun 2015 20:50:38 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:52014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z4f5F-0000BS-5D for emacs-devel@gnu.org; Mon, 15 Jun 2015 20:50:33 -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 2990A1C3853; Tue, 16 Jun 2015 09:50:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F1A801A2CA2; Tue, 16 Jun 2015 09:50:29 +0900 (JST) In-Reply-To: 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:187203 Archived-At: Drew Adams writes: > Beyond that, this change is at best a blunder. Speaking of demagogy. *This* is demagogy. No evidence has been provided that the change is a blunder. In fact, it can't be a blunder: the advantages and disadvantages are mostly matters of taste (including attitudes toward investment in specific kinds of tools). > It should be reverted. Maybe. We should make that decision based on having lots of users try it. The best way to try something like this is to install it and make it default while we're still in beta. > It is not just cosmetic. True. So what? Surely you don't propose we restrict future changes in Emacs to cosmetic changes! > > Just as some users dislike changes, possibly a lot, others dislike > > the status quo ante, possibly a lot. Why should a few reactionary > > curmudgeons :-) hold the progressives back? > > Demagogy & pandering, despite the smily. Wrong and wrong again. Pointing out that users have likes and dislikes and that they diverge radically is identifying the core issue that needs to be addressed here. And Alan *is* a reactionary and a curmudgeon, quick to oppose changes he doesn't initiate himself and well-set in his ways. There's nothing inherently wrong with those latter characteristics. It's just that catering to Alan here indeed does cost others an opportunity to improve their environments, and offer that improvement to those in the middle. > For shame. We see this kind of slight-of-hand charlatanism > employed all too often - those opposed to a purported innovation > are branded as "afraid of change". Reactionaries in my experience are rarely "afraid" of change in the sense of FUD. No, they oppose change for objective, if often selfish, reasons based on the *consequences* of change that they expect. > It is not about change vs no-change in general. It is about this > change. Which, based on the number of words you and Alan have devoted to attacking it, you believe to be the end of the world. That is an overreaction, enough to justify the term "reactionary" with respect to this specific issue. > For the same reason, though a superficial poll (of readers here > or of Emacs users) can tell us something, good arguments for and > against are generally more helpful. > > > It used to be a Bad Thing[tm]. Now, modern VCS means that such > > changes can be made and reverted quickly (although not always > > effortlessly or without help of developers experienced in the > > software), so rather than poll, just give them what you think they > > need. If they don't like it, you revert. That method provides far > > more accurate assessments of user sentiment than polling in advance, > > and is less costly (unless you're stupid enough to make such a > > change in a late beta). > > I'm not convinced. Momentum. Inertia. Emacs has momentum = 0 in the world at large, and it's basically inert in its development processes and strategic approach to the goals set for it by RMS. You think those are good things? I don't. > And there is no good reason *not* to bring such matters up for > discussion first (here, for example), and that can include > discussion with users. Sure there is. The first good reason for saying nothing is fear of attracting people who post long repetitive posts basically iterating and reiterating their personal tastes. The second good reason is that most people don't know what they really want, sometimes when they're quite sure about what they want. I've not only seen this occur repeatedly in others, I've experienced preference reversals in Emacs usage myself several times. CUA *is* a better default in the context of the world at large, active regions are generally a better UI, typing deletes active region is better UI. I opposed, fairly violently in some cases, all of those, based on various a priori arguments. But once I had experienced them I realized that they are more natural (well, the objective advantages of CUA are real but tiny, the main advantage is conformance to convention in the rest of the world, but the region changes provide a more coherent model of text editing) and are at least as efficient as the Emacs defaults were. Of course there are still arguments against each of those features, but I did change my mind. And I have seen others do so, also in the context of specific experience with features they had opposed. This change needs to be tested, not voted on a priori. > > Of course the proponents have to be cooperative. I know that Paul > > has a reasonably high opinion of his own opinions ;-), but I've also > > seen him revert patches for reasons of "general user taste", and with > > very little backtalk, on request. > > Consider this one such request, by one user. It's invalid in context of response to my post, because it's not based on specific experience but rather on FUD. That FUD may be based on relevant general experience -- but given the human bias toward opposing change, if specific experience can be gained cheaply, arguments based on general experience should be ignored. So can we all just shut up now, try the change, and let the leadership decide whether anything actually broke based on user reports? The one thing that remains to be said or not that is significant would be for Paul to acknowledge willingness to back out the change immediately on request from the project maintainers. With that, there's no reason I can see not to try it for a while. Steve