From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Experimentally unbind M-o on the trunk Date: Wed, 10 Feb 2021 11:10:00 -0800 Message-ID: References: <8ed9b43502ae1480e06b@heytings.org> <83r1lohqoc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2475"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) Cc: larsi@gnus.org, "Alfred M. Szmidt" , gregory@heytings.org, bugs@gnu.support, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 10 20:13:01 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 1l9uv5-0000XD-VD for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 20:12:59 +0100 Original-Received: from localhost ([::1]:59352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9uv4-0001E4-NO for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 14:12:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9usX-0008WG-NG for emacs-devel@gnu.org; Wed, 10 Feb 2021 14:10:24 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:61427) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9usO-0006cb-Oq; Wed, 10 Feb 2021 14:10:21 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id B667F40005; Wed, 10 Feb 2021 19:10:02 +0000 (UTC) In-Reply-To: <83r1lohqoc.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Feb 2021 17:45:55 +0200") Received-SPF: pass client-ip=217.70.183.194; envelope-from=matt@rfc20.org; helo=relay2-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:264327 Archived-At: Eli Zaretskii writes: >> From: "Alfred M. Szmidt" >> Date: Wed, 10 Feb 2021 10:12:20 -0500 >> Cc: gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org >> >> Sorry, I atleast have a hard time taking these suggestion to remap >> long standing keybindings randomly seriously, likewise suggestions >> that users should just resort to M-x or binding them themselves. > > Can you explain why you are so worried about Emacs changing the > default key bindings? Given that it takes one line in your .emacs to > restore any binding you care for, why argue so much about the > defaults? > > 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? I'd even take it up another level. Why are we satisfied with Emacs' current approach to exposing command based functionality to users? What we've got with Emacs today is a key binding resource exhaustion problem. But is moving bindings around the only way to address the problem? What if having a key binding was just one possible way to make a command easy and convenient to find and invoke. What if there were other equally good ways, and we all thought it would be strange to bind a precious key to a command if it were rarely used in practice? Case in point: if a command isn't bound to a key it doesn't show up in help, so there is this pressure to bind everything that could possibly be useful to some person some day to some key. What if instead help showed all the interactive commands provided by the mode? What if M-x were smarter about highlighting mode specific commands? Perhaps exploring these kinds of ideas would be useful.