-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:wq in org-capture-mode should do org-capture-finalize #5320
Comments
I also think that the Org Notes buffers (those that pop up to log a state change) should have the same behavior. Unfortunately, it looks like a solution similar to the one above does not work for the note buffers: (defun mw/evil-log-note ()
(evil-insert-state)
(evil-ex-define-cmd-local "q[uit]" 'org-kill-note-or-show-branches)
(evil-ex-define-cmd-local "wq" 'org-store-log-note))
(add-hook 'org-log-buffer-setup-hook 'mw/evil-log-note) With that hook, the Also, it's worth noting that Magit provides similar behavior, where |
I recently added That's the simplest way to do this. For example, for org-capture this should do the trick (define-key org-capture-mode-map [remap evil-save-and-close] 'org-capture-finalize)
(define-key org-capture-mode-map [remap evil-save-modified-and-close] 'org-capture-finalize)
(define-key org-capture-mode-map [remap evil-quit] 'org-capture-kill) Also works for |
Should be fixed in master. |
I think
org-capture
should play nice with the evil-ex commands:q
and:wq
. Right now, doing:wq
will write the captured item, but the capture buffer will remain open and none of the capture hooks are executed.Right now I do something like this:
This is faciliated by a nice little snippet from stack overflow that allows local ex bindings:
I think this behavior is expected by vim users and thus should be the default.
EDIT: I'd be happy to file a PR to fix this, but I'd appreciate some input on where to put the
evil-ex-define-cmd-local
code, as it's pretty generic. I imagine it'd go somewhere in the spacemacs-base init-evil code, but I wouldn't want putting something in there to prohibit what would otherwise be a simple fix in the org code from going through.The text was updated successfully, but these errors were encountered: