From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Thorpe Newsgroups: gmane.emacs.help Subject: Re: [External] : Re: not good proposal: "C-z " reserved for users Date: Sat, 13 Feb 2021 07:46:50 +0000 Message-ID: <874kig4dg5.fsf@robertthorpeconsulting.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23423"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, help-gnu-emacs@gnu.org, bugs@gnu.support To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 13 08:48:13 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1lApf2-000602-J0 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 08:48:12 +0100 Original-Received: from localhost ([::1]:50192 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lApf1-0004Jk-DL for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 13 Feb 2021 02:48:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lApeM-0004JU-QZ for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 02:47:30 -0500 Original-Received: from outbound-smtp22.blacknight.com ([81.17.249.190]:41873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lApeI-00031V-TM for help-gnu-emacs@gnu.org; Sat, 13 Feb 2021 02:47:30 -0500 Original-Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp22.blacknight.com (Postfix) with ESMTPS id 4EB6ABAE9A for ; Sat, 13 Feb 2021 07:47:23 +0000 (GMT) Original-Received: (qmail 32764 invoked from network); 13 Feb 2021 07:47:23 -0000 Original-Received: from unknown (HELO rt-inspiron-3480) (rt@robertthorpeconsulting.com@[109.76.74.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 13 Feb 2021 07:47:22 -0000 In-Reply-To: (message from Drew Adams on Fri, 12 Feb 2021 17:51:53 +0000) Received-SPF: pass client-ip=81.17.249.190; envelope-from=rt@robertthorpeconsulting.com; helo=outbound-smtp22.blacknight.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:127908 Archived-At: Drew Adams writes: > I agree that there are nuances, and that adding a key to an already > bound prefix key is less aggressive than binding a top-level key by > default. > > Good point. But let's at least start with a first-level > approximation. The problem is not so much the kind of thing you > describe there. The problem is things like Emacs suddenly deciding to > bind `C-x p', `C-x x', `C-x /' etc. by default. > > Details about possibly binding _any_ more keys by default should be > discussed generally, widely. That's not been done. A general > convention that Emacs should not do this is in order, IMHO. And I > made clear that exceptions can always be handled by good, general > discussion followed by maintainer decision. > > It's not black & white. There is a serious problem, and I think there > we should establish a general convention/rule/guideline/understanding > that Emacs should keep its mitts off keys not already bound. I see your points and I mostly agree. I definitely agree that there should be wider discussion before binding more keys by default. But I still think it would be useful to have one key that is gauranteed as Gregory Heyting suggests. Even if it were only gauranteed for a few years. Preferably, we should have both... Firstly, a general consensus to discuss new keybindings and not to introduce lots of them at once. Secondly, a single prefix-key specifically reserved for third-party packages. Also, there's still the issue of beginners. I still think that asking people to map keys themselves is unfriendly to new users. BR, Robert Thorpe