From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Fri, 05 Feb 2021 10:42:12 +0000 Message-ID: <5588fb258085d00c0e72@heytings.org> References: <87zh0mmr54.fsf@gmail.com> <87y2g5smya.fsf@gmail.com> <4FF55FBF-573D-4A70-B3FC-682CA25B7ECB@gnu.org> <83lfc53whk.fsf@gnu.org> <20210203180142.seu6o3i6u7jhkyrh@Ergus> <83eehx3to5.fsf@gnu.org> <20210203221628.xgvvxjvh56gyswba@Ergus> <20210204070033.pm4ido4hq7a6twif@Ergus> <83sg6brhyg.fsf@gnu.org> <5588fb25805d486be704@heytings.org> <878s82esdi.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21759"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Joost Kremers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 11:43:15 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 1l7ya3-0005Yp-Cc for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 11:43:15 +0100 Original-Received: from localhost ([::1]:52716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7ya2-0007Wk-CU for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 05:43:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7yZ6-00072T-R7 for emacs-devel@gnu.org; Fri, 05 Feb 2021 05:42:16 -0500 Original-Received: from heytings.org ([95.142.160.155]:37688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7yZ5-0003Ie-5E for emacs-devel@gnu.org; Fri, 05 Feb 2021 05:42:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1612521732; bh=d1s17beBgWV0uIjhbBdlfTN6jrcube1SK/q1CplCuK8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=OS2AYE44aRdvko6G+vUrZA526AbuHgQF6iYXirK5XibjZnAJMco9mbQYPRKmWm7nX Nh4ie6h4QLV9acsSoDd7FIlDf8oJVx5zX01WdcjpSGeCOoeJDqpGfJldhEg8lTEb/s nVx9+l/itnZ5grFmGgZsRtG33Gyh/8nvW/laL/Z4y+8Oml4irv97SEYAloVVSw1nbw il8UP6f/1ApW3ID2QwvIJ+byXzWEhj6gBb/Y04GQAFKRqDQzDsynhLg5nO7oIFP5RD ZASiw21kQxHGd/e2zuZ0O+vBkkgY6OQDc+m/W8HrwGsAe/lQ5aYIcCZRHSm2dACjl/ +LAfNFpnL1M4w== In-Reply-To: <878s82esdi.fsf@fastmail.fm> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-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:263968 Archived-At: > > Perhaps a better way to update the documented key binding conventions is > to add the rule that packages should generally not create global key > bindings. > That's another solution indeed, but IMO it is not a reasonable one. It is reasonable for a package to create global bindings, to write its documentation with these bindings, and for users to install the package and to access it through these bindings without having to set specific configuration options beforehand. It is IMO not reasonable to require from all users to add "global-set-key"s in their configuration before using a package. > > Reserving keys for external packages won't solve the fundamental problem > here: two external packages may still decide to use the same key > bindings, causing similar conflicts for users that install both. > That's a similar, but different problem: it's a conflict between package X and package Y, not a conflict between package X and Emacs. Moreover the likelihood that two packages use the same keys is much lower when many keys are available.