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.help Subject: Re: not good proposal: "C-z " reserved for users Date: Thu, 11 Feb 2021 13:15:41 +0000 Message-ID: References: <3966473cc17dcc4d4a30@heytings.org> <87y2fv2g5o.fsf@robertthorpeconsulting.com> <87mtwbym2r.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="23810"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Joost Kremers Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 11 14:47:24 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 1lACJY-0005xh-0x for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 11 Feb 2021 14:47:24 +0100 Original-Received: from localhost ([::1]:58004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lACJX-0007Zc-0f for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 11 Feb 2021 08:47:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lABoz-0005En-Df for help-gnu-emacs@gnu.org; Thu, 11 Feb 2021 08:15:51 -0500 Original-Received: from heytings.org ([95.142.160.155]:46452) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lABov-0006un-Hg for help-gnu-emacs@gnu.org; Thu, 11 Feb 2021 08:15:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1613049341; bh=OBntQFdaLi4+mMLXRGWPKwSY2D68HxPrl4OtTzcyV+I=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=joGw9tEKePcyV4ad4TvPEvvOe1/T9zCJ4ri3LJXzPxcbRgQKYko+k414mMUgHYHep P66SuTGIUS/HpOkwjVDibf5XhgClFso6wyLzSNr7JlDHec03CzUEGrGxRhuDOkA9hq HSn1K0LfokjSjdnGMEmltb6OPWoE+b7vO/hbW8iPnIj0ueZsRvoKvOAzZb2AQgHjgQ 0rCkcuouhRhv3uV9H3fUFOBW/U3brURsIvR2+/q3GL/ZJkK/sww1ltOloV2ls95J9X HIBogpVCdQnN5tkgflsp9r+s/UbFCbAV3uqTlOEU4ouIj3HmgVDi9d9legdoB/vsOi rAoIOG5AirVzg== In-Reply-To: <87mtwbym2r.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: 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:127808 Archived-At: > > Basically, I don't see a problem here that couldn't be solved much more > easily by updating the keybinding conventions to say that external > packages should not create any global bindings by default. > IMO that would be the worst possible solution, and would be an extremely negative signal towards third-party library developers. Do you remember that Emacs is an _extensible_ editor? See https://www.gnu.org/software/emacs/emacs-paper.html . Why shouldn't an extension package for a general-purpose editor (not necessarily Emacs, think Atom or Sublime or...) change the user interface of that editor when it is installed? > > Reserving keys for external packages means that Emacs needs some way to > deal with conflicting external key bindings, which will inevitably > arise. > Yes, and this has been acknowledged from the outset. It's a different problem however, these are conflicts between external packages, not between an external package and Emacs core or between an external package and users' personal bindings. And, as you yourself say, these conflicts can be handled by specific functions, in a user-friendly way. It can also be expected that best practices will arise by themselves, like "using as few keys as possible", "using a keymap on a single key if possible", "not using the same keys as an existing major package", "use the 4 key for commands in other-window and the 5 key for commands in other-frame", ...