emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Representation of the Emacs userbase on emacs-devel


From: Eli Zaretskii
Subject: Re: Representation of the Emacs userbase on emacs-devel
Date: Fri, 03 Sep 2021 09:28:34 +0300

> Cc: rms@gnu.org, John Yates <john@yates-sheets.org>, eliz@gnu.org,
>  danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]