From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2KUiFC/AHGBLAwAA0tVLHw (envelope-from ) for ; Fri, 05 Feb 2021 03:49:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id WL7tDy/AHGCwYQAAbx9fmQ (envelope-from ) for ; Fri, 05 Feb 2021 03:49:03 +0000 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 C3FC39402C2 for ; Fri, 5 Feb 2021 03:49:02 +0000 (UTC) Received: from localhost ([::1]:51378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7s7B-0005uT-Lt for larch@yhetil.org; Thu, 04 Feb 2021 22:49:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7s6e-0005uH-T1 for emacs-orgmode@gnu.org; Thu, 04 Feb 2021 22:48:28 -0500 Received: from ericabrahamsen.net ([52.70.2.18]:50214 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7s6d-00051t-CT for emacs-orgmode@gnu.org; Thu, 04 Feb 2021 22:48:28 -0500 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 21A81FA165; Fri, 5 Feb 2021 03:48:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1612496906; bh=eMyjKCuTAxICABrEI7jMzsVzhFTu9quqNG/fEh1xGqE=; h=From:To:Cc:Subject:References:Date:From; b=gm750zBTXk1YN/764Iqu3kMEDpOYQUV803AY3MjrPad13BztOl269dZudHdmjsQoE XO0qhzIQUjNM+L2ES7NKv5wTFwPFAfxOjooRVFNLsNQrZadcOUbOPeFIGlhPFHVCuY PSHzpktJHFNO5GzznQA4i9Jo6Mz61mkWHGiv36JU= From: Eric Abrahamsen To: Kyle Meyer Subject: Re: Free up C-c SPC/org-table-blank-field? References: <87im7k51u0.fsf@ericabrahamsen.net> <875z39y8ua.fsf@kyleam.com> Date: Thu, 04 Feb 2021 19:48:22 -0800 Message-ID: <871rdv6upl.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net 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, SPF_HELO_NONE=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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.55 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=ericabrahamsen.net header.s=mail header.b=gm750zBT; dmarc=pass (policy=none) header.from=ericabrahamsen.net; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: C3FC39402C2 X-Spam-Score: -0.55 X-Migadu-Scanner: scn0.migadu.com X-TUID: PVdesw6DR8IY Kyle Meyer writes: > Eric Abrahamsen writes: > >> Hi all, >> >> The C-c SPC keybinding is pretty prime property (it's also, according to >> Emacs conventions, meant to be reserved for the user, though I know >> that's already out the window with Org), > > Based on my reading of (info "(elisp)Key Binding Conventions"), I think > `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but > instead into the this group: > > Sequences consisting of =E2=80=98C-c=E2=80=99 followed by any other ASC= II > punctuation or symbol character are allocated for minor modes. > Using them in a major mode is not absolutely prohibited, but if you > do that, the major mode binding may be shadowed from time to time > by minor modes. Oh, interesting, thanks -- I've always found that section impossible to remember, and it seems to often be disregarded, anyway. In this case, I guess we could consider the keybinding to be kind of "minor-mode-ish", if you thought of commands that operate on Org tables to be like a minor mode that's only active when point is inside a table. [...] >> But, either way, I don't disagree with what you say next. >> >>> and it's currently bound to `org-table-blank-field', which is useless >>> unless you... happen to be in a table. I don't use tables often (or >>> blank fields when I do), which means this binding is effectively just >>> removed. > > Does it actually need a key binding? I've never used it and just use > to move to the next field, leaving the field blank. I assume it's meant for blanking a field you've already typed something into. But yes, I can't imagine it's a heavily-used command, and I suspect the C-c binding is mostly mnemonic: "make this field contain only blanks". >>> >>> What do people think about making it a no-op when not on a table >>> (letting it fall through to the global map), or putting it in a keymap >>> text property on tables, or otherwise not hogging the binding? >> >> In my view, the first would be fine, and the second also unless someone >> chimes in with a technical reason not to. For the last, perhaps `C-c >> C-SPC' would be an okay replacement, though I'd assume that would break >> some users' muscle memory in a surprising and unpleasant way. > > I'm not familiar with how this is all put together inside org mode. > If it is possible to configure things so that it is only bound when > inside a table and does not shadow other bindings for that sequence > outside a table, I think that would be a positive change. However, I do > also note that this is the type of change which tends to cause 'ripples' > and may have unexpected impact in other areas, such as other packages, > predefined or 'canned' emacs configurations etc. The way Org handles these situations now is to have a command that is named for its actual keybinding (eg `org-shiftmetaleft'), which then examines its context and dispatches to various other functions. That's a bit odd and not really how it's done in Emacs -- but I am not proposing we change this as it is pretty fundamental to how Org is set up and would wreck a bunch of stuff if it were changed. I thought Emacs might have some easy way to let a key event "fall through" to other keymaps, but I haven't been able to find anything immediately obvious. Maybe I can ask on emacs.devel... Eric