Re: Free up C-c SPC/org-table-blank-field?

[Tim Cross]

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.
>

Agreed.

> 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.

>>
>> 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.

--
Tim Cross