[Feature Request] More flexibility in org-speed-commands customization

[Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi All,

Org's speed keys are a very interesting feature to which I've long been 
attracted to.  And indeed, I've flirted with it a number of times in the 
past.  But every time I do so, I end up stepping back, because I get 
weary of fat fingering my documents.  The whole set of speed keys is 
more powerful than what I would wish.  I'd love to have speed keys for 
navigation and visibility, but I would also gladly refrain from these 
"too handy" editing keys.

As things stand, the speed keys are defined by combining 
`org-speed-commands-default', a defconst, and `org-speed-commands-user', 
a defcustom.  But the former already contains a large set of speed keys, 
including some quite powerful editing ones.  And it is thus hard to 
remove these keys.

Of course, it is possible.  We could shadow the same key in 
`org-speed-commands-user' to do nothing.  Or, though a defconst, 
`org-speed-commands-default' can be redefined after loading Org.  The 
first is clumsy, and renders the `org-speed-command-help' buffer quite 
confusing.  The second feels wrong (because it is).

I don't know if there is a strong reason to hard-code the set of keys in 
`org-speed-commands-default'.  But, if there isn't, could you consider 
(somehow) exposing the whole set of `org-speed-commands' to user 
customization?

Best,
Gustavo.

Re: [Feature Request] More flexibility in org-speed-commands customization

[Marco Wahl]

Hi Gustavo,

> Org's speed keys are a very interesting feature to which I've long
> been attracted to.  And indeed, I've flirted with it a number of times
> in the past.  But every time I do so, I end up stepping back, because
> I get weary of fat fingering my documents.  The whole set of speed
> keys is more powerful than what I would wish.  I'd love to have speed
> keys for navigation and visibility, but I would also gladly refrain
> from these "too handy" editing keys.
>
> As things stand, the speed keys are defined by combining
> `org-speed-commands-default', a defconst, and
> `org-speed-commands-user', a defcustom.  But the former already
> contains a large set of speed keys, including some quite powerful
> editing ones.  And it is thus hard to remove these keys.
>
> Of course, it is possible.  We could shadow the same key in
> `org-speed-commands-user' to do nothing.  Or, though a defconst, 
> `org-speed-commands-default' can be redefined after loading Org.  The
> first is clumsy, and renders the `org-speed-command-help' buffer quite 
> confusing.  The second feels wrong (because it is).
>
> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'.  But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?

This sounds like a good idea to me.

Do you already have a respective patch?


Best regards,
-- Marco

Re: [Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi Marco,

On Mon, 17 Aug 2020 at 06:40, Marco Wahl <marcowahlsoft@gmail.com> 
wrote:

>> I don't know if there is a strong reason to hard-code the set of keys
>> in `org-speed-commands-default'.  But, if there isn't, could you
>> consider (somehow) exposing the whole set of `org-speed-commands' to
>> user customization?
>
> This sounds like a good idea to me.
>
> Do you already have a respective patch?
>

thank you for considering this suggestion.  But, no, I haven't tried to 
prepare a patch, because even if I got it working, I wouldn't be able to 
contribute it.  Unfortunately, I cannot sign the papers given my current 
employment contract's terms.  So, for the foreseeable future, I'm stuck 
with this situation, and can only contribute with ideas, reports and 
such.

Best regards,
Gustavo.

Re: [Feature Request] More flexibility in org-speed-commands customization

[Bastien]

Hi Gustavo,

> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'.  But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?

Yes, I think the two variables should be merged into a single
`org-speed-commands' option.

Unless someone strongly objects, I will do after Org 9.4.

Thanks for the suggestion,

-- 
 Bastien

Re: [Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi Bastien,

On Fri, 04 Sep 2020 at 14:45, Bastien <bzg@gnu.org> wrote:

> Hi Gustavo,
>
>> I don't know if there is a strong reason to hard-code the set of keys
>> in `org-speed-commands-default'.  But, if there isn't, could you
>> consider (somehow) exposing the whole set of `org-speed-commands' to
>> user customization?
>
> Yes, I think the two variables should be merged into a single
> `org-speed-commands' option.
>
> Unless someone strongly objects, I will do after Org 9.4.
>
> Thanks for the suggestion,

Thank you for considering this suggestion.  I'm sure many people here 
have some fat-fingered "friend" who will rejoice to use the speed-keys 
with more tranquility.  ;-)

Best,
Gustavo.

Re: [Feature Request] More flexibility in org-speed-commands customization

[Bastien]

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

Hi Gustavo,

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'.  But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?

Well, no, I don't see a strong reason to hard-code the set of speedy
keys.  See the attached patch, which proposes to use just one option
`org-speed-commands'.

This would be a breaking change, but I don't think we do otherwise.

Would this suit your needs?  What do you think about the change?

-- 
 Bastien

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: refactor-speed-commands.patch --]
[-- Type: text/x-diff, Size: 5188 bytes --]

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 07ff85349..5da606b36 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -696,28 +696,6 @@ star at the beginning of the headline, you can do this:
 	  (const :tag "At beginning of headline stars" t)
 	  (function)))
 
-(defcustom org-speed-commands-user nil
-  "Alist of additional speed commands.
-This list will be checked before `org-speed-commands-default'
-when the variable `org-use-speed-commands' is non-nil
-and when the cursor is at the beginning of a headline.
-The car of each entry is a string with a single letter, which must
-be assigned to `self-insert-command' in the global map.
-The cdr is either a command to be called interactively, a function
-to be called, or a form to be evaluated.
-An entry that is just a list with a single string will be interpreted
-as a descriptive headline that will be added when listing the speed
-commands in the Help buffer using the `?' speed command."
-  :group 'org-structure
-  :type '(repeat :value ("k" . ignore)
-		 (choice :value ("k" . ignore)
-			 (list :tag "Descriptive Headline" (string :tag "Headline"))
-			 (cons :tag "Letter and Command"
-			       (string :tag "Command letter")
-			       (choice
-				(function)
-				(sexp))))))
-
 (defcustom org-speed-command-hook
   '(org-speed-command-activate org-babel-speed-command-activate)
   "Hook for activating speed commands at strategic locations.
@@ -737,7 +715,7 @@ hook.  The default setting is `org-speed-command-activate'."
   :version "24.1"
   :type 'hook)
 
-(defconst org-speed-commands-default
+(defcustom org-speed-commands
   '(("Outline Navigation")
     ("n" . (org-speed-move-safe 'org-next-visible-heading))
     ("p" . (org-speed-move-safe 'org-previous-visible-heading))
@@ -762,8 +740,7 @@ hook.  The default setting is `org-speed-command-activate'."
     ("l" . org-metaleft)
     ("R" . org-shiftmetaright)
     ("L" . org-shiftmetaleft)
-    ("i" . (progn (forward-char 1) (call-interactively
-				    'org-insert-heading-respect-content)))
+    ("i" . (progn (forward-char 1) (call-interactively 'org-insert-heading-respect-content)))
     ("^" . org-sort)
     ("w" . org-refile)
     ("a" . org-archive-subtree-default-with-confirmation)
@@ -782,8 +759,7 @@ hook.  The default setting is `org-speed-command-activate'."
     (":" . org-set-tags-command)
     ("e" . org-set-effort)
     ("E" . org-inc-effort)
-    ("W" . (lambda(m) (interactive "sMinutes before warning: ")
-	     (org-entry-put (point) "APPT_WARNTIME" m)))
+    ("W" . (lambda (m) (interactive "sMinutes before warning: ") (org-entry-put (point) "APPT_WARNTIME" m)))
     ("Agenda Views etc")
     ("v" . org-agenda)
     ("/" . org-sparse-tree)
@@ -792,7 +768,27 @@ hook.  The default setting is `org-speed-command-activate'."
     ("?" . org-speed-command-help)
     ("<" . (org-agenda-set-restriction-lock 'subtree))
     (">" . (org-agenda-remove-restriction-lock)))
-  "The default speed commands.")
+  "Alist of speed commands.
+
+The car of each entry is a string with a single letter, which
+must be assigned to `self-insert-command' in the global map.
+
+The cdr is either a command to be called interactively, a
+function to be called, or a form to be evaluated.
+
+An entry that is just a list with a single string will be
+interpreted as a descriptive headline that will be added when
+listing the speed commands in the Help buffer using the `?' speed
+command."
+  :group 'org-structure
+  :type '(repeat :value ("k" . ignore)
+		 (choice :value ("k" . ignore)
+			 (list :tag "Descriptive Headline" (string :tag "Headline"))
+			 (cons :tag "Letter and Command"
+			       (string :tag "Command letter")
+			       (choice
+				(function)
+				(sexp))))))
 
 (defun org-print-speed-command (e)
   (if (> (length (car e)) 1)
@@ -815,11 +811,8 @@ hook.  The default setting is `org-speed-command-activate'."
   (unless org-use-speed-commands
     (user-error "Speed commands are not activated, customize `org-use-speed-commands'"))
   (with-output-to-temp-buffer "*Help*"
-    (princ "User-defined Speed commands\n===========================\n")
-    (mapc #'org-print-speed-command org-speed-commands-user)
-    (princ "\n")
-    (princ "Built-in Speed commands\n=======================\n")
-    (mapc #'org-print-speed-command org-speed-commands-default))
+    (princ "Speed commands\n===========================\n")
+    (mapc #'org-print-speed-command org-speed-commands))
   (with-current-buffer "*Help*"
     (setq truncate-lines t)))
 
@@ -835,13 +828,11 @@ If not, return to the original position and throw an error."
 
 (defun org-speed-command-activate (keys)
   "Hook for activating single-letter speed commands.
-`org-speed-commands-default' specifies a minimal command set.
-Use `org-speed-commands-user' for further customization."
+See `org-speed-commands' for configuring them."
   (when (or (and (bolp) (looking-at org-outline-regexp))
 	    (and (functionp org-use-speed-commands)
 		 (funcall org-use-speed-commands)))
-    (cdr (assoc keys (append org-speed-commands-user
-			     org-speed-commands-default)))))
+    (cdr (assoc keys org-speed-commands))))
 
 \f
 ;;; Babel speed keys

Re: [Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi Bastien,

On Sat, 01 May 2021 at 13:24, Bastien <bzg@gnu.org> wrote:

> Hi Gustavo,
>
> Gustavo Barros <gusbrs.2016@gmail.com> writes:
>
>> I don't know if there is a strong reason to hard-code the set of keys
>> in `org-speed-commands-default'.  But, if there isn't, could you
>> consider (somehow) exposing the whole set of `org-speed-commands' to
>> user customization?
>
> Well, no, I don't see a strong reason to hard-code the set of speedy
> keys.  See the attached patch, which proposes to use just one option
> `org-speed-commands'.
>
> This would be a breaking change, but I don't think we do otherwise.
>
> Would this suit your needs?  What do you think about the change?

Thank you for seeing to this.

Yes, the patch corresponds pretty much to what I had in mind.  That's 
the way I'd go there too.

And it's not about my needs here, I can verify it is safe to override 
the defconst and do so (as indeed I do).  I was thinking more of that 
kind of user which would be uncertain if they could, and might 
eventually refrain from using a nice feature for framing it an "expert 
kind of stuff".

A possible way to mitigate breakage here can be at hand, since we ended 
up with a third name (a proper one, btw).  You could mark 
`org-speed-commands-user' as obsolete but keep it, for the due time as 
usual, and append it to `org-speed-commands' somehow (no need to 
distinguish them in `org-speed-command-help' though).  Those who had 
overriden `org-speed-commands-default' are on their own, of course, as 
they shouldn't have done that in the first place.  ;-)

Best regards,
Gustavo.

Re: [Feature Request] More flexibility in org-speed-commands customization

[Bastien]

Hi Gustavo,

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> A possible way to mitigate breakage here can be at hand, since we
> ended up with a third name (a proper one, btw).  You could mark
> `org-speed-commands-user' as obsolete but keep it, for the due time as
> usual, and append it to `org-speed-commands' somehow (no need to
> distinguish them in `org-speed-command-help' though).  Those who had
> overriden `org-speed-commands-default' are on their own, of course, as
> they shouldn't have done that in the first place.  ;-)

Indeed, I have some code ready for this in an updated version of the
patch. So the change won't be that "breaking" but let's still assess
whether it will break many configurations.

Thanks,

-- 
 Bastien

Re: [Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi Bastien,

On Sun, 02 May 2021 at 03:29, Bastien <bzg@gnu.org> wrote:

>
> Indeed, I have some code ready for this in an updated version of the
> patch. So the change won't be that "breaking" but let's still assess
> whether it will break many configurations.
>

Looks good to me. Thank you.

Gustavo.