From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.help Subject: Re: not good proposal: "C-z " reserved for users Date: Fri, 12 Feb 2021 11:14:43 +0100 Message-ID: <871rdltsfb.fsf@fastmail.fm> References: <3966473cc17dcc4d4a30@heytings.org> <87y2fv2g5o.fsf@robertthorpeconsulting.com> <87mtwbym2r.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22676"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.8; emacs 27.1.90 Cc: help-gnu-emacs@gnu.org To: Gregory Heytings Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 12 12:52:33 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 1lAWzw-0005nZ-Sy for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 12:52:32 +0100 Original-Received: from localhost ([::1]:50410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAWzv-00038e-V1 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 06:52:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAWzO-00037E-4X for help-gnu-emacs@gnu.org; Fri, 12 Feb 2021 06:51:58 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:44359) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAWzM-0003ar-1C for help-gnu-emacs@gnu.org; Fri, 12 Feb 2021 06:51:57 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4C0CD5C007B; Fri, 12 Feb 2021 06:51:55 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 12 Feb 2021 06:51:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= references:from:to:cc:subject:date:in-reply-to:message-id :mime-version:content-type; s=fm2; bh=kZ1QLTH95d2qABY1xNj3K3+L6N kDAl20ik1/OUNQuNA=; b=NRXBJuzW60ZM0HGNa6/4cTt1Ihf5aIv0iXK4twghTO 2TDmyVESMF7rd/LUkPE7ItudYkAQD8kINDO4H0t/dRNdMtLCo9kzf+U64evan5+w /mjkdGul1nb2Ndid7Yy2i4b8/LxEqXQ2rcFQUhkekhWMdXhkJbq/1FGmkEV/gYzX cP/28RGun6j5CmMNKB0Z2s9U9bdkUzj76lTTNLmKnWvZOHDfizF95wPW35cJ7XsO xY1FuMgOkIxb0eBX6cToqEPIATpcL2jPmha9YgJ8QWUoFcABh3kK4pzf1h97r/ZZ I5xs4Xvi91v/0fXuoFMS+hYfszY22yjM14znR3lXnJug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kZ1QLT H95d2qABY1xNj3K3+L6NkDAl20ik1/OUNQuNA=; b=oFl7Jw9aQiC0cgSqWdznGA LuNWCTCfSMt76Ol+2nFmNySNuYbh+UHAJxkdwALpgK7POCf9qW5yg/quCE1pYEXK wqCogx9QwNeBzYo5vCM2bFFYxIYRyTp7q/nxKhl35zFx9BzSplEfA3APM6JxWrYZ 9xCOPE6DKvxnkmsVOC/0UiGd4BzVfj9RLru+FnLOfxcEDWEj+dXnB285Aa9heBu7 9mNhbjjrkuPko01Q7XBYLAMJkKlBaF6a1/aazSGxq9YLOMT9sRYuGeBoThDW+xXR C3LwOGNA4N3jTEZ3sdYEefdAF7YHdad8PNB9CE+mr7omDlBYD4SH2RhqncHx22Kw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledriedugdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpehffgfhvffuffgjkfggtgesthdtredttdertdenucfhrhhomheplfhoohhsthcu mfhrvghmvghrshcuoehjohhoshhtkhhrvghmvghrshesfhgrshhtmhgrihhlrdhfmheqne cuggftrfgrthhtvghrnhepvdeihfetueevkeduteehudeihedvlefgieejhedvteefgeel leehhfejudeijeevnecukfhppeelhedrledurdduleejrdehjeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhoshhtkhhrvghmvghrshes fhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Original-Received: from Lenovo.fastmail.com (ip5f5bc539.dynamic.kabel-deutschland.de [95.91.197.57]) by mail.messagingengine.com (Postfix) with ESMTPA id 8499924005A; Fri, 12 Feb 2021 06:51:54 -0500 (EST) In-reply-to: Received-SPF: pass client-ip=66.111.4.29; envelope-from=joostkremers@fastmail.fm; helo=out5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:127843 Archived-At: On Thu, Feb 11 2021, Gregory Heytings wrote: >> >> 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. Why? It's been my interpretation of the intent of the key binding conventions and as a package maintainer I have never been bothered by it. In fact, I see it as a courtesy to the users of my packages that I do not stomp on whatever key bindings they may have set already. So I guess this comes down to very different views we have about what constitutes "user-friendly" in this particular case. > Do you remember > that Emacs is an _extensible_ editor? [I had a hostile reaction here to what I perceived to be a hostile remark from you. If that was a reaction to something I said, I apologise.] > 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? It depends on the change and the purpose of the package. Global key bindings are a limited resource, which is why I'd expect 3rd-party packages of any editor to be conservative about creating new ones. Same thing with the top-level menu, especially if a package wants to add a new item that is permanently visible. Adding a menu entry to an existing (sub)menu is fine, since they're more flexible (they can scroll, for example), but there, too, I'd expect 3rd-party packages to tread carefully (e.g., if you want to add a dozen new entries, then maybe put them together in a new submenu). For packages whose primary purpose is to change the user interface, it's different, of course. An Emacs package that exists to change global key bindings (evil comes to mind) are fine, because the user installs them for that purpose. But I don't install Magit to change my UI. Now, I've never used any other editor than Emacs (not seriously, anyway), but when I look at screen casts of people using Atom or PyCharm or something, they're clicking their way through the interface with skill and accuracy. If I were such a user, I wouldn't want an external package to suddenly change my menus for me, especially if part of the appeal of the editor I'm using is the fact that I can modify and lay out the menus in exactly the way I like. (I don't know if that's the case with Atom or Sublime or VSCode or any of the other editors out there, because, as I said, I've never used them.) >> 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. I don't really see it as a different problem. To me it's immaterial whether there's a conflict between Emacs and an external package, between two external packages or between a user's bindings and an external package; they're all conflicts caused by an external package creating a global key binding. > And, as you yourself say, these conflicts > can be handled by specific functions, in a user-friendly way. Yes. But the argument isn't that conflicts will arise. The argument is that in order to handle them properly, we need a system that is more complex than the alternative. And, in my opinion, too complex for the problem at hand. You obviously feel differently, which is fine. After all, in the end, what you or I feel isn't all that important. Just two more data points for the Emacs developers to make a decision. -- Joost Kremers Life has its moments