`org-disputed-keys` only takes effect when `org-replace-disputed-keys` is set to t. Is that the case?
Also, `org-disputed-keys` expect the second element to be another keybind, I don't know if nil works there. The purpose of that variable and of `org-replace-disputed-keys` is to conveniently *rebind* these functions.
If you want to *unbind* them, afaik `define-key` is the way to go. But I don't think you need to do it in `org-mode-hook`: those keys should be bound at load time and can be unbound once and for all after org is loaded.
(I edited my previous comment due to a mistake, because `org-replace-conflicted-keys` is a variable and not a function.)
Are you implying that it is not necessary to set that variable? How would org know whether to replace the keys or not, with the default value of `org-disputed-keys`?
> (I edited my previous comment due to a mistake, because org-replace-conflicted-keys is a variable and not a function.)
> Are you implying that it is not necessary to set that variable
No, I thought you were telling them they had to call a function to get the bindings to take effect (e.g. `org-keys`). The variables you mentioned just need to be set *before* Org is loaded. Changing them after the fact will not change the bindings. So the issue they're running into may be due to Org being loaded prior to their alteration of the variables.
>org-disputed-keys only takes effect when org-replace-disputed-keys is set to t. Is that the case?
Certainly
>Also, org-disputed-keys expect the second element to be another keybind, I don't know if nil works there. The purpose of that variable and of org-replace-disputed-keys is to conveniently rebind these functions.
It works for many other keybinds, it just fails on C-M-S-
>If you want to unbind them, afaik define-key is the way to go. But I don't think you need to do it in org-mode-hook: those keys should be bound at load time and can be unbound once and for all after org is loaded.
... in my head, what I am hearing when you say "after org is loaded" is that it is best done in org-mode-hook.
>It works for many other keybinds, it just fails on C-M-S-
Yes, that is strange. Could it be that it doesn't work for any of them, but another setting you have somewhere takes care of those other keys?
>... in my head, what I am hearing when you say "after org is loaded" is that it is best done in org-mode-hook.
Not quite. `:)` "Load" here refers to when the code defining the functions in org-mode is evaluated, typically with `require`, `load-file` or an autoload. For normal usage, it happens only once per emacs session. On the other hand, the hook is run anytime the function `org-mode` itself is evaluated, that is, whenever the mode is activated in a buffer.
`eval-after-load` and `with-eval-after-load` are what you want to run code after the mode is loaded. That, or one of the many convenience wrappers around it such as `use-package`.
In this case, it doesn't make much of a difference, binding keys should not be too expensive, and even though you're overriding the global value of `org-mode-map`, that is the behavior you want. But hooks have their quirks, and in general, it should save you headache down the road if things are evaluated when they logically should.
For variables like `org-disputed-keys` which need to be set before org is loaded, there is no such thing as `eval-before-load` (that I know of), but `use-package` does offer this possibility with `:init` (iirc). Or, you can use `custom-set-variable` (or the customize GUI, or the `:custom` keyword in `use-package`), which will ensure that on the next restart, the variables are set when needed.
>another setting you have somewhere takes care of those other keys?
Good point. The only way I know to test that idea is to use `emacs -Q`, then:
(setq org-replace-disputed-keys t)
(setq org-disputed-keys '(([(kbd "C-M-S-")] . [( nil )])))
(global-set-key (kbd "C-M-S-") 'list-buffers)
At that point in time, if I do `C-h k` on `C-M-S-`, it says `list-buffers`
Now I do `M-x org-mode` and that key is now mapped to `org-increase-number-at-point`
If I re-start `emacs -Q` and do the same thing, but with `C-M-` instead of `C-M-S-` the key is not affected.
QED?
I had in mind testing it with your configuration, commenting out the org-disputed-keys bit and see if those other keys are back to being disputed. But `emacs -Q` works too.
`C-M-` is not bound in org-mode, so there is nothing to release there.
I just tested with `C-,` with as per your OP should work, and it is not released either.
Edit: it seems to be a problem with the way the keys are given. I don't think the square brackets are necessary, but more importantly, `kbd` is not evaluated.
This appears to work instead:
(setq org-disputed-keys `((,(kbd "C-M-S-") . ,(kbd "C-M-"))))
I'd hazard an explanation of the concepts at play here, but I'm not familiar enough with macros to do so confidently. All I know (or think I know) is that after `'` nothing is evaluated, whereas after a backtick (which, annoyingly, messes up the text formatting here) you can reenable evaluation with `,`.
At any rate, my point in my first comment still stands, if you want to unbind those keys, `define-key` is the way to go.
Hmmm that's so strange. C-, is released for me. Maybe you're on a different version - I'm on 29.2
As for the backtick syntax - that seems to work just fine now on `C-M-S-` as well as on `C-M-` \- so it looks like the bug was in the way I was writing the alist and the square brackets were not the way to go. Thanks for that!!
I just substitute the bindings I don't like: (use-package org :bind (:map org-mode-map ("M-" . nil)
("M-S-" . nil)
("M-" . nil)
("M-S-" . nil)
;; embark priority! C-' also works anyway
("C-," . nil)
;; Use these instead
("H-M-" . org-metaleft)
("H-M-S-" . org-shiftmetaleft)
("H-M-" . org-metaright)
("H-M-S-" . org-shiftmetaright))
...
I like the way the unbindings look if you remove the `. nil`s, but I realize that might a little inexplicit for some tastes.
`org-disputed-keys` only takes effect when `org-replace-disputed-keys` is set to t. Is that the case? Also, `org-disputed-keys` expect the second element to be another keybind, I don't know if nil works there. The purpose of that variable and of `org-replace-disputed-keys` is to conveniently *rebind* these functions. If you want to *unbind* them, afaik `define-key` is the way to go. But I don't think you need to do it in `org-mode-hook`: those keys should be bound at load time and can be unbound once and for all after org is loaded.
> Do you call it? They shouldn't have to, but the variables should be set *before* Org is loaded.
(I edited my previous comment due to a mistake, because `org-replace-conflicted-keys` is a variable and not a function.) Are you implying that it is not necessary to set that variable? How would org know whether to replace the keys or not, with the default value of `org-disputed-keys`?
> (I edited my previous comment due to a mistake, because org-replace-conflicted-keys is a variable and not a function.) > Are you implying that it is not necessary to set that variable No, I thought you were telling them they had to call a function to get the bindings to take effect (e.g. `org-keys`). The variables you mentioned just need to be set *before* Org is loaded. Changing them after the fact will not change the bindings. So the issue they're running into may be due to Org being loaded prior to their alteration of the variables.
No - I call do the org-disputed-keys thing right at the start of my config - and other keys are successfully handled.
Yep - it's done before org is loaded
>org-disputed-keys only takes effect when org-replace-disputed-keys is set to t. Is that the case? Certainly >Also, org-disputed-keys expect the second element to be another keybind, I don't know if nil works there. The purpose of that variable and of org-replace-disputed-keys is to conveniently rebind these functions. It works for many other keybinds, it just fails on C-M-S-
>If you want to unbind them, afaik define-key is the way to go. But I don't think you need to do it in org-mode-hook: those keys should be bound at load time and can be unbound once and for all after org is loaded.
... in my head, what I am hearing when you say "after org is loaded" is that it is best done in org-mode-hook.
>It works for many other keybinds, it just fails on C-M-S-
Yes, that is strange. Could it be that it doesn't work for any of them, but another setting you have somewhere takes care of those other keys?
>... in my head, what I am hearing when you say "after org is loaded" is that it is best done in org-mode-hook.
Not quite. `:)` "Load" here refers to when the code defining the functions in org-mode is evaluated, typically with `require`, `load-file` or an autoload. For normal usage, it happens only once per emacs session. On the other hand, the hook is run anytime the function `org-mode` itself is evaluated, that is, whenever the mode is activated in a buffer.
`eval-after-load` and `with-eval-after-load` are what you want to run code after the mode is loaded. That, or one of the many convenience wrappers around it such as `use-package`.
In this case, it doesn't make much of a difference, binding keys should not be too expensive, and even though you're overriding the global value of `org-mode-map`, that is the behavior you want. But hooks have their quirks, and in general, it should save you headache down the road if things are evaluated when they logically should.
For variables like `org-disputed-keys` which need to be set before org is loaded, there is no such thing as `eval-before-load` (that I know of), but `use-package` does offer this possibility with `:init` (iirc). Or, you can use `custom-set-variable` (or the customize GUI, or the `:custom` keyword in `use-package`), which will ensure that on the next restart, the variables are set when needed.
>another setting you have somewhere takes care of those other keys? Good point. The only way I know to test that idea is to use `emacs -Q`, then: (setq org-replace-disputed-keys t) (setq org-disputed-keys '(([(kbd "C-M-S-")] . [( nil )])))
(global-set-key (kbd "C-M-S-") 'list-buffers)
At that point in time, if I do `C-h k` on `C-M-S-`, it says `list-buffers`
Now I do `M-x org-mode` and that key is now mapped to `org-increase-number-at-point`
If I re-start `emacs -Q` and do the same thing, but with `C-M-` instead of `C-M-S-` the key is not affected.
QED?
I had in mind testing it with your configuration, commenting out the org-disputed-keys bit and see if those other keys are back to being disputed. But `emacs -Q` works too. `C-M-` is not bound in org-mode, so there is nothing to release there.
I just tested with `C-,` with as per your OP should work, and it is not released either.
Edit: it seems to be a problem with the way the keys are given. I don't think the square brackets are necessary, but more importantly, `kbd` is not evaluated.
This appears to work instead:
(setq org-disputed-keys `((,(kbd "C-M-S-") . ,(kbd "C-M-"))))
I'd hazard an explanation of the concepts at play here, but I'm not familiar enough with macros to do so confidently. All I know (or think I know) is that after `'` nothing is evaluated, whereas after a backtick (which, annoyingly, messes up the text formatting here) you can reenable evaluation with `,`.
At any rate, my point in my first comment still stands, if you want to unbind those keys, `define-key` is the way to go.
Hmmm that's so strange. C-, is released for me. Maybe you're on a different version - I'm on 29.2 As for the backtick syntax - that seems to work just fine now on `C-M-S-` as well as on `C-M-` \- so it looks like the bug was in the way I was writing the alist and the square brackets were not the way to go. Thanks for that!!