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

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

[Eric Abrahamsen]

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

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?

Thanks,
Eric

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

[Kyle Meyer]

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.

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

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

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

[Eric Abrahamsen]

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

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

[Kyle Meyer]

Eric Abrahamsen writes:

> Kyle Meyer <kyle@kyleam.com> 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".

[ Just for clarity: from this point on, the outer text you were quoting
  was from Tim Cross, not me. ]

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

Yeah, I don't know either.  When I read your initial message, I assumed
you were thinking of some sort of key lookup.  Something like below
seems to works, but it feels hacky and is probably pretty brittle.


diff --git a/lisp/org-table.el b/lisp/org-table.el
index ef4672e1b..c6d0e91c4 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -1203,22 +1203,28 @@ (defun org-table-goto-line (N)
     (= cnt N)))
 
 ;;;###autoload
-(defun org-table-blank-field ()
+(defun org-table-blank-field (&optional interactive-p)
   "Blank the current table field or active region."
-  (interactive)
-  (org-table-check-inside-data-field)
-  (if (and (called-interactively-p 'any) (org-region-active-p))
-      (let (org-table-clip)
-	(org-table-cut-region (region-beginning) (region-end)))
-    (skip-chars-backward "^|")
-    (backward-char 1)
-    (if (looking-at "|[^|\n]+")
-	(let* ((pos (match-beginning 0))
-	       (match (match-string 0))
-	       (len (org-string-width match)))
-	  (replace-match (concat "|" (make-string (1- len) ?\ )))
-	  (goto-char (+ 2 pos))
-	  (substring match 1)))))
+  (interactive "p")
+  (cond
+   ((org-at-table-p)
+    (org-table-check-inside-data-field)
+    (if (and interactive-p (org-region-active-p))
+        (let (org-table-clip)
+          (org-table-cut-region (region-beginning) (region-end)))
+      (skip-chars-backward "^|")
+      (backward-char 1)
+      (if (looking-at "|[^|\n]+")
+          (let* ((pos (match-beginning 0))
+                 (match (match-string 0))
+                 (len (org-string-width match)))
+            (replace-match (concat "|" (make-string (1- len) ?\ )))
+            (goto-char (+ 2 pos))
+            (substring match 1)))))
+   (interactive-p
+    (let ((key (lookup-key (current-global-map) (this-command-keys))))
+      (unless (numberp key)
+        (call-interactively key))))))
 
 (defun org-table-get-field (&optional n replace)
   "Return the value of the field in column N of current row.

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

[Tim Cross]

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

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

[Christian Moe]

Tim Cross writes:

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

One can also blank a field by pressing <SPC> immediately after tabbing
into it. So C-c <SPC> isn't strictly needed.

(Though since you typically discover you want to blank a field only when
you're actually in it, it can help shave a few seconds off your day that
you'd otherwise use to move out of the field you want to blank and tab
back in ... which is how I've done this until now, being unaware of C-c
<SPC>).

Yours,
Christian

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

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Fri, Feb 5, 2021 at 11:13 AM Christian Moe <mail@christianmoe.com> wrote:

>
> Tim Cross writes:
>
> > 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.
>
> One can also blank a field by pressing <SPC> immediately after tabbing
> into it. So C-c <SPC> isn't strictly needed.
>

Hi,

I think there would be minimal impact from releasing this key binding.  So
I think we could remove it.

Carsten


>
> (Though since you typically discover you want to blank a field only when
> you're actually in it, it can help shave a few seconds off your day that
> you'd otherwise use to move out of the field you want to blank and tab
> back in ... which is how I've done this until now, being unaware of C-c
> <SPC>).
>
> Yours,
> Christian
>
>

[-- Attachment #2: Type: text/html, Size: 2176 bytes --]

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

[Eric Abrahamsen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Fri, Feb 5, 2021 at 11:13 AM Christian Moe <mail@christianmoe.com> wrote:
>
>>
>> Tim Cross writes:
>>
>> > 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.
>>
>> One can also blank a field by pressing <SPC> immediately after tabbing
>> into it. So C-c <SPC> isn't strictly needed.
>>
>
> Hi,
>
> I think there would be minimal impact from releasing this key binding.  So
> I think we could remove it.

Well that would be pretty nice, if you don't think it would be too
disruptive. Shall I prepare a patch?

Thanks,
Eric

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

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

On Fri, Feb 5, 2021 at 7:33 PM Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe <mail@christianmoe.com>
> wrote:
> >
> >>
> >> Tim Cross writes:
> >>
> >> > 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.
> >>
> >> One can also blank a field by pressing <SPC> immediately after tabbing
> >> into it. So C-c <SPC> isn't strictly needed.
> >>
> >
> > Hi,
> >
> > I think there would be minimal impact from releasing this key binding.
> So
> > I think we could remove it.
>
> Well that would be pretty nice, if you don't think it would be too
> disruptive. Shall I prepare a patch?
>

I am not taking the decisions, but I would say: yes, please do.

Carsten

>
> Thanks,
> Eric
>

[-- Attachment #2: Type: text/html, Size: 2499 bytes --]

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

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Fri, Feb 5, 2021 at 7:33 PM Eric Abrahamsen <eric@ericabrahamsen.net>
> wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>> > On Fri, Feb 5, 2021 at 11:13 AM Christian Moe <mail@christianmoe.com>
>> wrote:
>> >
>> >>
>> >> Tim Cross writes:
>> >>
>> >> > 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.
>> >>
>> >> One can also blank a field by pressing <SPC> immediately after tabbing
>> >> into it. So C-c <SPC> isn't strictly needed.
>> >>
>> >
>> > Hi,
>> >
>> > I think there would be minimal impact from releasing this key binding.
>> So
>> > I think we could remove it.
>>
>> Well that would be pretty nice, if you don't think it would be too
>> disruptive. Shall I prepare a patch?
>>
>
> I am not taking the decisions, but I would say: yes, please do.

That took a while, for such a simple patch! Hope this is acceptable.

Thanks,
Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-default-binding-for-org-table-blank-field.patch --]
[-- Type: text/x-patch, Size: 1472 bytes --]

From c7d246b20f56bcc89a23d523ebf64a2f67c58bc6 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 4 Mar 2021 11:44:12 -0800
Subject: [PATCH] Remove default binding for org-table-blank-field

* lisp/org-keys.el: The command isn't useful enough to occupy such a
useful keybinding as "C-c SPC".
---
 lisp/org-keys.el | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index f0fdb79ea..07ff85349 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -174,7 +174,6 @@
 (declare-function org-show-subtree "org" ())
 (declare-function org-sort "org" (&optional with-case))
 (declare-function org-sparse-tree "org" (&optional arg type))
-(declare-function org-table-blank-field "org" ())
 (declare-function org-table-copy-down "org" (n))
 (declare-function org-table-create-or-convert-from-region "org" (arg))
 (declare-function org-table-create-with-table\.el "org-table" ())
@@ -620,7 +619,6 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names."
 (org-defkey org-mode-map (kbd "RET") #'org-return)
 (org-defkey org-mode-map (kbd "C-j") #'org-return-and-maybe-indent)
 (org-defkey org-mode-map (kbd "C-c ?") #'org-table-field-info)
-(org-defkey org-mode-map (kbd "C-c SPC") #'org-table-blank-field)
 (org-defkey org-mode-map (kbd "C-c +") #'org-table-sum)
 (org-defkey org-mode-map (kbd "C-c =") #'org-table-eval-formula)
 (org-defkey org-mode-map (kbd "C-c '") #'org-edit-special)
-- 
2.30.1

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

[Bastien]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> That took a while, for such a simple patch! Hope this is acceptable.

... and it took a while to install it, but finally done with commit
7a1c8cadf. 

Thanks!

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

[Eric Abrahamsen]

On 04/28/21 05:50 AM, Bastien wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> That took a while, for such a simple patch! Hope this is acceptable.
>
> ... and it took a while to install it, but finally done with commit
> 7a1c8cadf. 
>
> Thanks!

Awesome, thank you!