emacs-devel
[Top][All Lists]
Advanced

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

Re: Suggested experimental test


From: Eli Zaretskii
Subject: Re: Suggested experimental test
Date: Tue, 23 Mar 2021 10:06:11 +0200

> Date: Mon, 22 Mar 2021 20:22:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> >>> This question also goes to everyone else in this long dispute who 
> >>> wants their precious key bindings preserved: why is such a long 
> >>> discussion needed when it is so easy to restore, in your init file, a 
> >>> binding you want preserved?
> >
> > Sure.  But what I wrote then didn't prevent you-all from flooding this 
> > list with precisely the discussions I tried to prevent.
> 
> I'm sorry for this, that's not what I wanted.  What would be the way to 
> conduct such an experiment without provoking such a flooding, for those 
> who do not have write access to the trunk?

I basically think you cannot.  Any such theme is bound to produce a
long heated discussion.  We cannot do anything practical to prevent
it.  That's life.

> IMO Emacs is now in a position that is similar to that of Emacs 16, when 
> RMS introduced modes.  He realized that he needed a prefix key for them, 
> and he did not choose to use one of the yet unused meta keys: instead he 
> repurposed C-c and moved its command somewhere else.  The need for such a 
> prefix key is something that he could not have envisioned while writing 
> Emacs 1, it became apparent only later.  Likewise, some time later, when 
> user configuration files became common, the C-c LETTER keys were freed. 
> Again the need for this could not have been seen beforehand, and again RMS 
> did not choose to use a free meta key for this.
> 
> Now the situation is that third-party packages are becoming more and more 
> popular, something which couldn't have been envisioned twenty years ago, 
> and these packages can't be installed in a simple way, that is, without 
> asking users to fiddle with their configuration files, to define some 
> global key bindings that these packages need.  I don't see why we 
> shouldn't act in the same way RMS acted, that is, by repurposing one 
> control key for them.

The difference is that 37 years have passed, and what was then a
recent keybinding in a program that had only a very limited user base
is now a keybinding many users have hardwired into their muscles.

Another thing that changed is that there are nowadays many more active
contributors to Emacs who have their own (and different!) views on
this subject.  See below.  It was easy to make such decisions when
Emacs was an RCS repository on Richard's own machine, and he was the
only one who actually made changes.

Yet another thing that's changed is that we nowadays have much fewer
free keys to work with, and many of those, while unbound globally, are
likely to be bound by some mode which is dear to someone.  Part of the
reasons for the differences in opinions is that different people use
different modes and have different usage patterns, and thus keybinding
that are important to some might be unimportant (or even unknown, as
these discussions repeatedly show!) to others.  How can we ever
significantly agree on removing or changing a keybinding under these
circumstances?

And one more thought, regarding the problem that 3rd-party packages
have: it can be argued that this is not our problem.  Why should users
of Emacs that never heard of package P and will likely never use it
pay the price? why couldn't the developers of P solve the problem
which is in a way caused by P and whose solution benefits the users of
P?  Some might think that shifting the price to the Emacs core is the
wrong way of dealing with the problem.  The solution could be for P to
use longer key sequences (which usurps fewer keys on the top level),
and if some users of P are unhappy about that, then those users could
rebind the commands privately to any key they like.  Think about it.



reply via email to

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