From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Representation of the Emacs userbase on emacs-devel Date: Fri, 03 Sep 2021 09:28:34 +0300 Message-ID: <837dfyyxyl.fsf@gnu.org> References: <87h7fcnmq0.fsf@posteo.net> <83tujbqg4j.fsf@gnu.org> <46353190-1190-495f-b15e-22980159b3ab@yandex.ru> <83y28mp0rb.fsf@gnu.org> <51a363db-fde7-791d-cf8d-98ac601d62ee@yandex.ru> <57ca4d78-2339-201d-edce-678c9b003a99@yandex.ru> <83bl5dsh8b.fsf@gnu.org> <8335qps8vs.fsf@gnu.org> <9471c28f-8eae-b555-ee86-9fffd6229937@yandex.ru> <87r1e690n8.fsf_-_@posteo.net> <9d5a2f83-d564-22e1-0cbd-df760044528f@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31382"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 03 08:29:20 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mM2hU-0007tu-HF for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Sep 2021 08:29:20 +0200 Original-Received: from localhost ([::1]:52044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM2hT-0006kx-7S for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Sep 2021 02:29:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM2gx-00066r-Fm for emacs-devel@gnu.org; Fri, 03 Sep 2021 02:28:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:32996) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM2gw-0007BN-1j; Fri, 03 Sep 2021 02:28:46 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2952 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM2go-00017W-H6; Fri, 03 Sep 2021 02:28:39 -0400 In-Reply-To: <9d5a2f83-d564-22e1-0cbd-df760044528f@yandex.ru> (message from Dmitry Gutov on Fri, 3 Sep 2021 01:39:05 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273750 Archived-At: > Cc: rms@gnu.org, John Yates , eliz@gnu.org, > danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 3 Sep 2021 01:39:05 +0300 > > > I agree that the ability for a handful of users to veto changes can be > > annoying, but how harmful it is should be decided on a case-to-case > > basis. Do you (or anyone else) have any examples of where one or just a > > few people prevented a change from being made that you think would have > > been good in your eyes? > > Every recent discussion about a UI change has been like that. A > suggestion is made, arguments added, some people disagree saying it > won't jive with their workflow (never mind that Emacs is, in fact, > customizable), and that's it. For example, the thread about bindings for > undo-only+undo-redo, which would make Emacs friendlier to any user with > experience in about any other text editing program out there. That's only true for changes of the default behavior, and key bindings are examples of such a change, at least the way they are proposed. There was talk about introducing a minor mode which would then be free to make controversial changes, including key bindings, but no one stepped forward to write such a mode. Which I think is a pity, given how easy it should be to do that, and how many problems and frustrations it could potentially solve. Once again: significant changes in behavior should generally be introduced as opt-in features, then the friction will be much lower and in the long run we could perhaps introduce changes at a faster pace. Thus, people who insist on making changes in the default behavior are shooting themselves (and Emacs, if their opinions are right) in the foot, IME. > Or take indent-tabs-mode, an old pet peeve of mine: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20322 I can talk about > contemporary practice, whole-industry polls, threads with personal > opinions anywhere, threads with people expressing confusion about the > current default behavior... but a few people say a change will be > inconvenient -- and it moves nowhere. indent-tabs-mode is an existing option, so your insistence on turning it on by default in the face of resistance is ... peculiar. We did turn it on in some of our sources.