From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id +FtwJ1pX+WNJTgAAbAwnHQ (envelope-from ) for ; Sat, 25 Feb 2023 01:33:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id eIhzJ1pX+WPhUQAA9RJhRA (envelope-from ) for ; Sat, 25 Feb 2023 01:33:30 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7A197132E0 for ; Sat, 25 Feb 2023 01:33:30 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=red-bean.com header.s=202005newsp header.b=SNdosFRV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=red-bean.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1677285210; a=rsa-sha256; cv=none; b=UXwg+r0PC56H8MdyWZX7wNtqmYCtsC2yohT+sO4Mr1/jTumL1CgWg4OKkhSQUz8s5/UUFl ZXfi6XeJ9Yv3pN/jJEA+G1eMe1ku+0VyoPXydISCuX+o5ecBMjfpN1IYrqd+JF/vnO55ka HzhlXZ4kSVEm9Zf5E+nUZl9F0XIiWCLstLkX+nzWvk/z5jnXeYT1+Ja9bsXLyDz+IwVHn/ jdbSN+le+UkE0aVu44S6WYSugUgfuluxO7Sa/EdEfCF3UYcJPoAIRjdiT9IcUivTpBWdsM IW7i6XxntyPGVrbnQmPYEBJsr/FfsnThLu7Ge7cUxaPuZzgOOCrf530gsbBwhA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=red-bean.com header.s=202005newsp header.b=SNdosFRV; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=red-bean.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1677285210; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to:in-reply-to: references:references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=DXm6ZveiJO25a5sFqmku+iq1XnGblI2ra+I+qCGscUo=; b=YqLADyUksQn1g1R1qZiV+NB/wIaqWq2SagsKbH3/xxw8VQI7Y72bl1Dl0U5ES7CzcLkEoe 9l0yOMKFJz2nHXej7/BeP0J91cmnpDurM+5IAAaxfBTwoqI6U6ZDjgnSA5zXcMzSMR5vAk l39GL7yzcar8W6bUMeYfVtmegGKerql3QOOb1kaq1VyePYb9e1qHdC6tMcx28GHIGNTluJ PL5jmKwhh+O/C1m2ZnenI3w+pewIffhx2TP6fP5txiRdEYnFTmk65+CJ7/EzRx7TdUdiMp KZ0dsSf2YGgkLZgCNgz5kW8iJijVClSKHUsetmwAi6N2EwlAJx6Oy8KQ27Bs8Q== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pViBp-0006fG-05; Fri, 24 Feb 2023 19:13:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pViBn-0006er-4D for emacs-orgmode@gnu.org; Fri, 24 Feb 2023 19:13:23 -0500 Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pViBl-0000ji-FC for emacs-orgmode@gnu.org; Fri, 24 Feb 2023 19:13:22 -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:Date: Reply-To:References:In-Reply-To:Subject:To:From:Sender:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=DXm6ZveiJO25a5sFqmku+iq1XnGblI2ra+I+qCGscUo=; t=1677283997; x=1678493597; b=SNdosFRVr/CYRsbI5l7r4S5rVtkVE4MH/MkB8we4b4+nrIxozklK8a0PExJj3EbO+/qGwFTYTdp j9MPGjJ8sSNoZE/Y1OhksEYxLuUbtEsXYowA7vA0bXHZNTQmhMJviCfbvOGhus4038LJ8xstqez2/ l+UtC9jY258y9jw/kxmQrJptsYXvcZldKtRlwEvfSKUw0x0Pbw9QiXSFZqKt329vRYftcDP23S0Hr 2ab/ej5YAfOQ6ucnO7vSWRPfJVdzHmgdH/emaVuBNkoFzqbFeP0/JAVesg1h0CxHYDSfGy5xa2nMQ +TvG3T+wXjV1iIqMY/RL2sRqD0DRqXrSrcFA==; Received: from [12.106.183.66] (port=55521 helo=hummy) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pViBe-00Gk1R-V6 for emacs-orgmode@gnu.org; Sat, 25 Feb 2023 00:13:15 +0000 From: Karl Fogel To: emacs-orgmode@gnu.org Subject: Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode. In-Reply-To: (Max Nikulin's message of "Thu, 23 Feb 2023 09:35:46 +0700") In-Reply-To: <87mt54tdc8.fsf@red-bean.com> References: <87k00aw43b.fsf@red-bean.com> <87356xws6i.fsf@red-bean.com> References: <87k00aw43b.fsf@red-bean.com> <87356xws6i.fsf@red-bean.com> <87mt54tdc8.fsf@red-bean.com> Date: Fri, 24 Feb 2023 18:13:14 -0600 Message-ID: <87cz5y7gbp.fsf@red-bean.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; format=flowed 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-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: X-Migadu-Queue-Id: 7A197132E0 X-Spam-Score: 4.02 X-Migadu-Spam-Score: 4.02 X-Migadu-Scanner: scn0.migadu.com List-Subscribe: , Reply-To: Karl Fogel Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-TUID: OaHkBq3w6ZZ8 Okay, today I did some research and found that every "C-c C-" binding is used in Org Mode except for "C-c C-g". While that one is technically reserved for the mode's use, I suspect the reason it's unbound is that people are accustomed to using C-g as a quit command (and they get that effect if they accidentally type C-c, because then they type C-g and it's just an undefined key -- i.e., it quits, which is what the user wanted). Note that while "C-c C-h" does not appear to be bound, it actually is: it gets you a help buffer about the Org Mode keybindings (which then, ironically, does not list "C-c C-h" as one of the bindings). (It's not clear to me whether Emacs's conventions consider "C-c C-i" to be a letter or whether they treat "C-i" as "TAB" and consider it special; based on the previous evidence in this thread, maybe the latter, so we shouldn't consider "C-c C-i" to be available.) I think what this is telling me is that Org Mode keybinding real estate is quite valuable :-), and that unless there are other people who feel as strongly as I do that `org-fold-hide-subtree' is amazingly useful, we probably won't decide to bind it by default in Org Mode. So I should just continue to bind it to a custom key myself and continue to live a glorious life all alone in my private keymap splendour. Best regards, -Karl I wrote: >On 23 Feb 2023, Max Nikulin wrote: >>On 23/02/2023 00:01, Karl Fogel wrote: >>> =C2=A0(when (not (keymap-lookup nil "C-")) >>> =C2=A0=C2=A0 (keymap-local-set "C-" >>> 'org-fold-hide-subtree)) >>> So FWIW C- is not bound in Org Mode buffers for me, in=20 >>> Emacs >>> 30.x (i.e., recent development builds). >> >>lisp/tab-bar.el:130: (unless (global-key-binding [(control=20 >>tab)]) >>lisp/tab-bar.el:131: (global-set-key [(control tab)]=20 >>#'tab-next)) >> >>Minibuffer file cache completion should not be relevant to >>Org=20 >>buffers. > >Ah, I don't use tab-bar at all (at least not as far as I know), >so=20 >I'm not 100% sure what the above is saying. > >Are you saying that the only current default binding for >C-=20 >in Emacs is that one in tab-bar.el, and therefore we should >feel=20 >free to rebind it in Org Mode? If so, we should still be=20 >cautious, since Emacs has policies for maintaining the >keybinding=20 >space. Generally, the space "C-c C-" is reserved for=20 >major modes, so ideally we should find something in there if >we=20 >can -- although Org Mode has used up a lot of that space >already=20 >:-), so I'm not sure what's left, unless we decide to swap out=20 >some existing binding in favor of this one. > >(I realize this contradicts what I said in my inital post. I >had=20 >forgotten that C- was not part of the mode-reserved space.)