From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Concern about new binding. Date: Fri, 05 Feb 2021 20:31:19 -0600 Message-ID: <87ft2arkp4.fsf@red-bean.com> References: <87zh0mmr54.fsf@gmail.com> <83lfc53whk.fsf@gnu.org> <20210203180142.seu6o3i6u7jhkyrh@Ergus> <83eehx3to5.fsf@gnu.org> <20210203221628.xgvvxjvh56gyswba@Ergus> <20210204070033.pm4ido4hq7a6twif@Ergus> <83sg6brhyg.fsf@gnu.org> <87a6sjpyqs.fsf@gnus.org> <838s83ra3q.fsf@gnu.org> <87mtwjocn7.fsf@gnus.org> <87wnvnmqhx.fsf@gnus.org> <87o8gz40ex.fsf@red-bean.com> <87czxfm0t8.fsf@gnus.jao.io> <877dnmt79i.fsf@red-bean.com> <874kiqm0yu.fsf@gnus.jao.io> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20775"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: jao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 06 03:32:00 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 1l8DOC-0005Hj-Ce for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Feb 2021 03:32:00 +0100 Original-Received: from localhost ([::1]:45250 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8DOB-0004gW-D5 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 21:31:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58382) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8DNd-0004Eq-1J for emacs-devel@gnu.org; Fri, 05 Feb 2021 21:31:25 -0500 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]:45022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8DNa-0006ge-TC; Fri, 05 Feb 2021 21:31:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:Reply-To:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Gkm8Yx/U4O5bRkE15fYVNSfLGwM52cJp3CxaKrkA5oQ=; t=1612578681; x=1613788281; b=BjER0gq+XYyLGIkyA8od7r8thZnELvre8F4Z0nbw1bzy+zz9SWRNtwDAoT5GbavqYKeVuMu5tp MNUQZqi90Bn4NCLmc5Eit4ia4lf3uhVSroOcoSvn3rr+1LV2cjj0H0hvgOT5UWm23L6RuIM1L0+xI qSVPfTP/Ne2VoJqijk7SJ5qEqoW2tFvM2/2AFEGbCffO6LF1lgxItkYK80/hgoO5fNCjBBkEaIBi1 j0bJDNiZhrT+vfCherluUZCjcpujlKPlUHcyJ+GFDSt35stfSjGpzuU/ei6JHxWAA85mcJl7eJIZA lgi7IXpt//1gM1JNAa4UK+4xN+BGpKSJFojqQ==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:34172 helo=floss) by sanpietro.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l8DNY-0001l2-Oi; Sat, 06 Feb 2021 02:31:20 +0000 In-Reply-To: <874kiqm0yu.fsf@gnus.jao.io> (jao@gnu.org's message of "Sat, 06 Feb 2021 01:36:25 +0000") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com 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:264037 Archived-At: On 06 Feb 2021, jao wrote: >On Fri, Feb 05 2021, Karl Fogel wrote: >> On 05 Feb 2021, Jose A. Ortega Ruiz wrote: Ah, I can answer >> this. It has to do with protecting investment. >> >> When I custom-bind a command to a key, I am making an >> investment in finger memory. For example, I have >> `revert-buffer' on `C-c r' (because I use `revert-buffer' a >> lot), and I chose `C-c r' precisely because it was in the >> reserved space for user-chosen keybindings. That way I could >> be sure Emacs would never bind some other useful new function >> there. >> >> Imagine if Emacs *were* to bind some other useful new function >> there by default. Then I would face a hard choice: give up my >> finger memory for `revert-buffer' (by moving my binding for it >> to somewhere else), or custom-bind Emacs's new useful function >> to some key different than where Emacs wanted to put it. > Oh, but "moving the binding of revert-buffer" is not what we're >discussing. We're discussing (or, well, /i/ was discussing, >perhaps i misunderstood) assigning a currently unbound command to >a currently unassigned key. Sure, but my answer to your question is still the same answer. I'm arguing that Emacs make explicit commitments about keeping some keyspaces free in the default distribution, in order to favor users who are likely to make long-term investments in custom keybindings. It already does this with `C-c LETTER', of course. I'm just saying let's make the same commitment a few more places. The justification for this would be to create more places where users will feel safe to make finger-memory investments. >> Every such decision (to move a default Emacs keybinding to >> somewhere else) will cause me to diverge a bit further from >> default Emacs, > Yes, i agree that /moving/ an already assigned binding to a >"free" key is a bad idea. I was thinking of creating new ones. I hope it was clear, but just in case it wasn't: my paragraph was talking about *me*, the user, moving a recently-changed default Emacs keybinding to somewhere else, just in my Emacs, in order to preserve a custom binding in its current place. And I was just explaining why even though any user is free to do this, it still has costs for that user, and therefore we should try to help users not be in the position of facing that choice. You stated elsewhere that you think Emacs should never replace an existing default keybinding with a different default keybinding. I don't know if we have that policy, but if we do, then the problem I'm worried about would not exist, that's true. >[...] > >Well, i gladly diverge in that sense, and occupy any existing >binding that i never use with a personal one that i use 10 times >an hour (or even once a day, or a week). And, at the same time, >i'd rather see (say) C-x r bound to a command that the emacs >maintainers find useful, than empty--on behalf of vanilla emacs >users without heavy customizations (which include, i suppose, a >majority of newbies). This is a genuine difference of opinion, yes. There are good arguments on both sides here, I think. My argument has long been that Emacs should prioritize the needs of investment-oriented users. That is, to make Emacs slightly worse for the investment-oriented users in order to make it better for those who are unlikely to invest is usually the wrong decision. You wrote "newbies" above, but I think it's important to distinguish between two kinds of newbies: the investment-oriented ones, and the ones who are unlikely to invest. Your assertion is true for the latter kind, but not the former. Some newbies will *eventually* be highly invested users who are looking in the crowded keymap landscape for some free space to put their customizations :-). >Yes, thank you. I hope i've also been able to clarify a bit my >(in some ways, opposite) perspective (BTW, for 3rd-party >libraries, my stance is quite different; i think they should >never define any top-level keybinding, and put instead all their >commands in a keymap with a configurable prefix, whose value >would be asked on first interactive use, informing the user of >what commands her prefix choice is overriding. but that's >wishful thinking :)). Yes, you did succeed in clarifying, and I appreciate it! Best regards, -Karl