From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Philip K." Newsgroups: gmane.emacs.help Subject: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages Date: Fri, 12 Feb 2021 11:27:09 +0100 Message-ID: <87czx5a947.fsf@posteo.net> References: <7ef75c33936136eb3a20@heytings.org> <8735y56naf.fsf@posteo.net> <8ed9b43502ae9a36b057@heytings.org> <87tuqk6d9d.fsf@posteo.net> <3966473cc1ab9f104724@heytings.org> <87o8gr1oom.fsf@posteo.net> <87lfbubthl.fsf@posteo.net> <87tuqia845.fsf@posteo.net> <87pn16a1xn.fsf@posteo.net> <87lfbu9q5x.fsf@posteo.net> <329d68a5ed6d1194f3c0@heytings.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5029"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) 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 11:28:15 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 1lAVgM-0001Bw-Rd for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 11:28:14 +0100 Original-Received: from localhost ([::1]:43922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAVgL-0002O8-U3 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 12 Feb 2021 05:28:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36974) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAVfR-0002Kb-9F for help-gnu-emacs@gnu.org; Fri, 12 Feb 2021 05:27:17 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:41026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAVfN-0007gc-QA for help-gnu-emacs@gnu.org; Fri, 12 Feb 2021 05:27:15 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id A08E51600B3 for ; Fri, 12 Feb 2021 11:27:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1613125631; bh=HyK3l/tn48DdEyJeLY6rGEWmZSy4OeOjqQi3maT7SLo=; h=From:To:Cc:Subject:Date:From; b=gmZX46VMkTLk4JQ+/XRaTADIJN2mhNsLROp9g8Q1WRNihmR75IgIq2crtjlm+6FEW Xxko5i8jUj51yyueilstzxI0illvT0UMr4AettPF/UX8D1lbJQdNa7YyGpLPVYtHid wOCam/VS17m2iK3WoVQQsTcR5wkNT+ent9qv0aPjQDx7zB3yq/dX7O1JwIGinoII/s x8luOIb020o8jkAkYrwu4zs2V7JHoGQRwHSeGnzDZIhK1v1iWEPdYHAEZxOAvDKZ/T is2JJuFrWXWTSyaT6z8xhBuX3YMZ5Ckzny0XuT0GkO/HNgnfhAMRQLljY/waCNpHBB 52hyX71UhNUPA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DcV6k45P8z6tm8; Fri, 12 Feb 2021 11:27:10 +0100 (CET) In-Reply-To: <329d68a5ed6d1194f3c0@heytings.org> (Gregory Heytings's message of "Fri, 12 Feb 2021 00:01:51 +0000") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=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: 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:127842 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Gregory Heytings writes: >> A theme doesn't activate when it is installed or loaded, but when it >> is activated. In the same way, I argue, a command shouldn't bind >> itself until it is bound. Note that I don't insist that this has to >> be done by editing your init.el (as shown in the patch from a few >> messages before). I just think that loading a feature/package should >> attempt to just load the package, without changing the UI/UX of the >> system. > > I fear you're splitting hairs here: the distinction between "install", > "load" and "activate" is not important in this discussion, with the=20 > current state of affairs neither installing nor loading nor activating > the package can automatically create a global key binding. The > proposal is an attempt to make that possible. Well none of these should so it, with the possible exception of activating, that I'll mention again below. But I still think that the distinction is important, if only because it is real. I recently realized there would be another problem with this approach, as you also mentioned that global modes should activate themselves on installation, specifically naming Ivy, the completing-read framework. But what if someone decides to install Helm? Will these two modes now interfere, possibly breaking everything, or is it Helm's responsibility to deactivate Ivy. If so, does every completion framework have to know about every other one? I think this shows that adding code like ;;;###autoload (ivy-mode t) is bad style, even if a beginner manages to deactivate Ivy or Helm, the same issue would arise every time Emacs is restarted, which creates the feeling that the entire system is fragile -- and it is, because fundamental operations like "install", "load" and "activate" are kept apart. As for key-bindings, if we assume that like Magit, any package can just autoload a global-set-key, we are just inviting bug-reports complaining about "Key sequence [something] starts with non-prefix key [something else]", or key-bindings being over-ridden or chaining from session to session. Situations like these, tell me that adding user-customization directly as autoloaded code is harmful and would at least require a level of abstraction in-between. >>> Do you also think it's a mistake and unfriendly if a package >>> installs a menu item? If not, what makes keybindings fundamentally >>> different from menu items? >> >> Do you mean a menu-bar-mode item? Yes, loading a package still >> shouldn't change anything, activating a mode should add the menu >> item > > Okay, so if you agree that activating a mode can automatically add a > menu bar item, why don't you agree that it should be possible to > automatically add a global key binding while activating a mode? > Again, what makes key bindings fundamentally different from menu bar > items? Activating a mode and deactivating a mode are "inverse" operations. This is important, because it makes mode activation reversible, and lets the user feel like he or she is in control. Therefore, if a global-minor-mode, which I assume we are talking about, binds a global key, it must not only un-bind it when it is done, but restore the previous binding, if there was one. The tricky part is now if a second global-minor-mode comes along, and wants to rebind the same key, also saves the same command and then installs it's command: Now deactivating the first mode would either have to check if the key it has bound is still bound, and only undo it's operation if that is the case, or it just re-binds the old key, overriding the binding of the second minor mode. Neither of these are good approaches, and they cannot be resolved without both global-minor-modes either knowing details about one-another or having a protocol they follow to save keys. The difference to menu items is that collisions like these are not possible, you just add and remove an item from a list, without having to fear collision (with the possible exception of having two items have the same name, but that's an issue on a different level). This demonstrates why a mode binding a key to the global-map is difficult, and why it should instead use it's own map, that is installed when said mode is activated. =2D-=20 Philip K. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEbW+YL3e0aNnYosjIGB9bla4wszYFAmAmV/0ACgkQGB9bla4w szbaswv+OrTib15cFXfydBpLU6uLiTSnbWfiqnr9JhTxBspUyC3xEFvJKtsm8kEe qfG7M0rmzl3XaBV2SW6/nHlDeTpw+egHlKtJDGAafUfV4pWs2vfwNV/wpF7yxUSq rjGu2RErK3a8PW2hG8FEZJ+k2PBEwiheydxZdhuNH/VAuYKSEWDBVDb6pudacBN2 n+TIE+GUOneFvD3ZUNe/9w+JjePhHK3rZ2Vyao7uF/HFzHUuENaXwQ52Ha/Rw2s5 7fmm+9Hs6J7ezFpNvNpFPMwsAGQF1ZM7E96HfCmDUP58KXca8CKksmb91h5+LApF lJvn8KroxHcM7Y8L+3ytMuU1O9T88RWHjMzgnMJt/o10vSsbaFqLMz44EdMk5/f6 WXz0hRFSrq57d7YTP7CCVBgVKAE8fMwxULdRB8HxfP0wDyiSdKhXjRY2NCNk8ejz 0ZwKmEx/7ZvrQyKDr/0LVbJzfyK/QBOcPJI6vBHlV6mhV+e63OESb28zmpMdDAFv XapcM6Eb =9JWX -----END PGP SIGNATURE----- --=-=-=--