[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Free up C-c SPC/org-table-blank-field?
From: |
Eric Abrahamsen |
Subject: |
Re: Free up C-c SPC/org-table-blank-field? |
Date: |
Thu, 04 Feb 2021 19:48:22 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Kyle Meyer <kyle@kyleam.com> 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 ‘C-c’ followed by any other ASCII
> 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
> <tab> 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 <SPC> 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