From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Free up C-c SPC/org-table-blank-field?
Date: Fri, 05 Feb 2021 16:32:21 +1100 [thread overview]
Message-ID: <87im77njpx.fsf@gmail.com> (raw)
In-Reply-To: <871rdv6upl.fsf@ericabrahamsen.net>
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> 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".
>
I guess that makes sense, but not convinced the use of a valuable key
binding is justified given the need. Then again, others probably have
vastly different use cases to mine.
>>>>
>>>> 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...
>
I don't believe there is one. I think the basic model is a hierarchy of
key maps with bindings and the first match wins. I guess the only option
is to add a more sophisticated context test and only perform the action
if the context is inside a table cell. If not inside a table cell,
either perform some function which makes sense. It could be that on
loading, org checks to see if there is a binding and stores that as the
default action outside of tables or if we have some action which would
make sense, bind to that or keep it simple and have it defined as a user
option which defaults to a noop and allow the user to define something
if they want?
Since switching to spacemacs and its 'evil' key binding model, I've
become very aware of the dangers associated with modes that try to be
too clever when it comes to key bindings. I think they are really quite
a personal thing and best kept as simple as possible. In general, org
has been reasonably successful with its rather 'advanced' approach, but
there have been times I've found it frustrating. Smart key bindings are
great when they do what you expect, but when they don't....
--
Tim Cross
next prev parent reply other threads:[~2021-02-05 5:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 18:05 Free up C-c SPC/org-table-blank-field? Eric Abrahamsen
2021-02-03 6:16 ` Kyle Meyer
2021-02-03 6:26 ` Tim Cross
2021-02-05 3:48 ` Eric Abrahamsen
2021-02-05 4:45 ` Kyle Meyer
2021-02-05 5:32 ` Tim Cross [this message]
2021-02-05 9:41 ` Christian Moe
2021-02-05 10:44 ` Carsten Dominik
2021-02-05 18:33 ` Eric Abrahamsen
2021-02-11 9:45 ` Carsten Dominik
2021-03-04 19:49 ` Eric Abrahamsen
2021-04-28 3:50 ` Bastien
2021-05-01 21:09 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im77njpx.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).