mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/emacs/.emacs.d/wpc/keybindings.el

271 lines
8.5 KiB
EmacsLisp
Raw Normal View History

Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
;;; keybindings.el --- Centralizing my keybindings -*- lexical-binding: t -*-
;; Author: William Carroll <wpcarro@gmail.com>
;;; Commentary:
;; Attempting to centralize my keybindings to simplify my configuration.
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
;;
;; I have some expectations about my keybindings. Here are some of those
;; defined:
;; - In insert mode:
;; - C-a: beginning-of-line
;; - C-e: end-of-line
;; - C-b: backwards-char
;; - C-f: forwards-char
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
;;; Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Dependencies
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'clipboard)
(require 'screen-brightness)
Bind chrome/browse to EXWM keybinding I'm hoping to use `chrome/browse` more often!
2020-01-20 13:13:36 +01:00
(require 'chrome)
Ensure scrot.el initializes - Adds scrot to init.el - Moves the EXWM keybindings to keybindings.el
2020-01-20 17:48:42 +01:00
(require 'scrot)
Add missing require for ivy-clipmenu Adding the missing dependency requirement for keybindings.el
2020-01-27 12:25:32 +01:00
(require 'ivy-clipmenu)
Support KBDs for term-switcher package To facilitate transitioning from using `terminator` to using `vterm`, I'm defining some KBDs that I hope will help me habituate my usage of `vterm`.
2020-02-02 13:14:34 +01:00
(require 'general)
Debug evil-want-keybindings issue Problem: dependency loading order I originally assumed that keybindings.el was the first module to `require 'evil` because init.el shows: ```elisp (require 'keybindings) (require 'window-manager) ``` The problem is that keybindings.el calls `require 'window-manager` and window-manager.el requires evil! I admit, I've created a bit of a birds nest for myself. A few thoughts: - keybindings.el doesn't need to `require 'window-manager`. Fixed! - window-manager.el shouldn't need to `require 'evil`. TODO...
2020-08-19 17:47:57 +02:00
(require 'exwm)
Support vterm-mgt.el I enjoyed using term-switcher so much that I ended up adopting vterm as my primary terminal. After reaching for vterm as often as I did, I realized that I would enjoy supporting cycling through instances, creating new instances, deleting existing instances, renaming instances. Thus spawned vterm-mgt.el. I'm particularly excited about the KBD to toggle between vterm instances and source code buffers.
2020-02-08 17:00:31 +01:00
(require 'vterm-mgt)
(require 'buffer)
Support cycling through display configurations Today when I opened my laptop, I wasn't sure if it was powered off or on because the display was blank. Thankfully the volume was muted and the LED indicator was on, which informed me that the laptop was powered on. This saved me from unnecessarily rebooting. What happened was that last night I was working from home and using my external monitor. Usually I enable my external display and disable my laptop display. But when I left for work this morning, I unplugged the HDMI cable from my laptop without disabling the external display or enabling the laptop display. I noticed a XF86 button on my laptop entitled XF86Display. I figured that this could be a nice place to bind a key to toggle my laptop display on or off. At the last minute, I had the idea to just cycle through all possible display configurations that I use; there are only three anyways. When dealing with more than two states, I realized I should use a cycle to model the configuration states. Now I'm thinking that I should be using cycles to model toggles as well - instead of just using a top-level variable that I `setq` over. I haven't refactored existing toggles to be cycles, but I am excited about this new keybinding. This commit additionally: - Moves keybindings out of display.el and into keybindings.el - Conditionally sets KBDs if using work laptop
2020-02-11 12:00:24 +01:00
(require 'display)
(require 'device)
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
Drop use-package in keybindings.el I'm attempting to kill that zombie bug about evil-want-keybinding...
2020-08-19 17:34:30 +02:00
;; Note: The following lines must be sorted this way.
(setq evil-want-integration t)
(setq evil-want-keybinding nil)
(general-evil-setup)
(require 'evil)
(require 'evil-collection)
(require 'evil-magit)
(require 'evil-commentary)
(require 'evil-surround)
(require 'key-chord)
;; Ensure that evil's command mode behaves with readline bindings.
(general-define-key
:keymaps 'evil-ex-completion-map
"C-a" #'move-beginning-of-line
"C-e" #'move-end-of-line
"C-k" #'kill-line
"C-u" #'evil-delete-whole-line
"C-v" #'evil-paste-after
"C-d" #'delete-char
"C-f" #'forward-char
"M-b" #'backward-word
"M-f" #'forward-word
"M-d" #'kill-word
"M-DEL" #'backward-kill-word
"C-b" #'backward-char)
(general-mmap
:keymaps 'override
"RET" #'evil-goto-line
"H" #'evil-first-non-blank
"L" #'evil-end-of-line
"_" #'ranger
"-" #'dired-jump
"sl" #'wpc/evil-window-vsplit-right
"sh" #'evil-window-vsplit
"sk" #'evil-window-split
"sj" #'wpc/evil-window-split-down)
(general-nmap
:keymaps 'override
"gd" #'xref-find-definitions
;; Wrapping `xref-find-references' in the `let' binding to prevent xref from
;; prompting. There are other ways to handle this variable, such as setting
;; it globally with `setq' or buffer-locally with `setq-local'. For now, I
;; prefer setting it with `let', which should bind it in the dynamic scope
;; for the duration of the `xref-find-references' function call.
"gx" (lambda ()
(interactive)
(let ((xref-prompt-for-identifier nil))
(call-interactively #'xref-find-references))))
(general-unbind 'motion "M-." "C-p" "<SPC>")
(general-unbind 'normal "s" "M-." "C-p" "C-n")
(general-unbind 'insert "C-v" "C-d" "C-a" "C-e" "C-n" "C-p" "C-k")
(setq evil-symbol-word-search t)
(evil-mode 1)
(evil-collection-init)
(evil-commentary-mode)
(global-evil-surround-mode 1)
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
;; Ensure the Evil search results get centered vertically.
(progn
(defadvice isearch-update
(before advice-for-isearch-update activate)
(evil-scroll-line-to-center (line-number-at-pos)))
(defadvice evil-search-next
(after advice-for-evil-search-next activate)
(evil-scroll-line-to-center (line-number-at-pos)))
(defadvice evil-search-previous
(after advice-for-evil-search-previous activate)
(evil-scroll-line-to-center (line-number-at-pos))))
Drop use-package in keybindings.el I'm attempting to kill that zombie bug about evil-want-keybinding...
2020-08-19 17:34:30 +02:00
(key-chord-mode 1)
(key-chord-define evil-insert-state-map "jk" 'evil-normal-state)
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
;; General KBDs
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
;; This may be contraversial, but I never use the prefix key, and I'd prefer to
;; have to bound to the readline function that deletes the entire line.
(general-unbind "C-u")
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
(defmacro keybinding/exwm (c fn)
"Bind C to FN using `exwm-input-set-key' with `kbd' applied to C."
`(exwm-input-set-key (kbd ,c) ,fn))
(keybinding/exwm "C-M-v" #'ivy-clipmenu/copy)
(keybinding/exwm "<XF86MonBrightnessUp>" #'screen-brightness/increase)
(keybinding/exwm "<XF86MonBrightnessDown>" #'screen-brightness/decrease)
Debug keybindings.el Change `keybindings/` -> `keybinding/`. Whoops...
2020-01-20 13:13:11 +01:00
(keybinding/exwm "<XF86AudioMute>" #'pulse-audio/toggle-mute)
(keybinding/exwm "<XF86AudioLowerVolume>" #'pulse-audio/decrease-volume)
(keybinding/exwm "<XF86AudioRaiseVolume>" #'pulse-audio/increase-volume)
(keybinding/exwm "<XF86AudioMicMute>" #'pulse-audio/toggle-microphone)
Bind chrome/browse to EXWM keybinding I'm hoping to use `chrome/browse` more often!
2020-01-20 13:13:36 +01:00
(keybinding/exwm "C-M-c" #'chrome/browse)
Ensure scrot.el initializes - Adds scrot to init.el - Moves the EXWM keybindings to keybindings.el
2020-01-20 17:48:42 +01:00
(keybinding/exwm (kbd/raw 'x11 "s") #'scrot/select)
Support focusing EXWM X-application buffers Press `<M-escape.` to display a list of buffers hosting X applications. Use `completing-read` to select and focus one of these. See the function docs and TODOs for more information.
2020-02-02 14:20:55 +01:00
(keybinding/exwm "<C-M-tab>" #'exwm/switch-to-exwm-buffer)
Drop support for wpc-keybindings In favor of keybindings.el! Now I have: - kbd.el: There are no keybindings in this file. It's just a library for working with keybindings in Emacs. - keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
2020-08-19 13:42:11 +02:00
(general-define-key
:keymaps 'override
"M-q" #'delete-window
"<s-return>" #'toggle-frame-fullscreen
"M-h" #'windmove-left
"M-l" #'windmove-right
"M-k" #'windmove-up
"M-j" #'windmove-down
"M-q" #'delete-window)
;; Support pasting in M-:.
(general-define-key
:keymaps 'read-expression-map
"C-v" #'clipboard-yank
"C-S-v" #'clipboard-yank)
Define KBD for find-file-at-point (i.e. ffap) I'm attempting to incorporate the beloved find-file-at-point function into my workflow.
2020-02-18 12:01:57 +01:00
(general-define-key
:prefix "<SPC>"
:states '(normal)
Centralize <SPC> in normal mode KBDs Merging keybinding and wpc-keybindings step-by-step...
2020-08-19 13:27:15 +02:00
"." #'ffap
"gn" #'notmuch
"i" #'counsel-semantic-or-imenu
"I" #'ibuffer
"hk" #'helpful-callable
"hf" #'helpful-function
"hm" #'helpful-macro
"hc" #'helpful-command
"hk" #'helpful-key
"hv" #'helpful-variable
"hp" #'helpful-at-point
"s" #'flyspell-mode
"S" #'sort-lines
"=" #'align
"p" #'flycheck-previous-error
"f" #'project-find-file
"n" #'flycheck-next-error
"N" #'smerge-next
"W" #'balance-windows
"gs" #'magit-status
"E" #'refine
"es" #'wpc/create-snippet
"l" #'linum-mode
"B" #'magit-blame
"w" #'save-buffer
"r" #'wpc/evil-replace-under-point
"R" #'deadgrep)
Define KBD for find-file-at-point (i.e. ffap) I'm attempting to incorporate the beloved find-file-at-point function into my workflow.
2020-02-18 12:01:57 +01:00
Support vterm-mgt.el I enjoyed using term-switcher so much that I ended up adopting vterm as my primary terminal. After reaching for vterm as often as I did, I realized that I would enjoy supporting cycling through instances, creating new instances, deleting existing instances, renaming instances. Thus spawned vterm-mgt.el. I'm particularly excited about the KBD to toggle between vterm instances and source code buffers.
2020-02-08 17:00:31 +01:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Vterm
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Show or hide a vterm buffer. I'm intentionally not defining this in
;; vterm-mgt.el because it consumes `buffer/show-previous', and I'd like to
;; avoid bloating vterm-mgt.el with dependencies that others may not want.
(general-define-key (kbd/raw 'x11 "t")
(lambda ()
(interactive)
(if (vterm-mgt--instance? (current-buffer))
(switch-to-buffer (first (buffer/source-code-buffers)))
(call-interactively #'vterm-mgt-find-or-create))))
(general-define-key
:keymaps '(vterm-mode-map)
"C-S-n" #'vterm-mgt-instantiate
"C-S-w" #'vterm-mgt-kill
"<C-tab>" #'vterm-mgt-next
"<C-S-iso-lefttab>" #'vterm-mgt-prev
"<s-backspace>" #'vterm-mgt-rename-buffer)
Support KBDs for term-switcher package To facilitate transitioning from using `terminator` to using `vterm`, I'm defining some KBDs that I hope will help me habituate my usage of `vterm`.
2020-02-02 13:14:34 +01:00
Support cycling through display configurations Today when I opened my laptop, I wasn't sure if it was powered off or on because the display was blank. Thankfully the volume was muted and the LED indicator was on, which informed me that the laptop was powered on. This saved me from unnecessarily rebooting. What happened was that last night I was working from home and using my external monitor. Usually I enable my external display and disable my laptop display. But when I left for work this morning, I unplugged the HDMI cable from my laptop without disabling the external display or enabling the laptop display. I noticed a XF86 button on my laptop entitled XF86Display. I figured that this could be a nice place to bind a key to toggle my laptop display on or off. At the last minute, I had the idea to just cycle through all possible display configurations that I use; there are only three anyways. When dealing with more than two states, I realized I should use a cycle to model the configuration states. Now I'm thinking that I should be using cycles to model toggles as well - instead of just using a top-level variable that I `setq` over. I haven't refactored existing toggles to be cycles, but I am excited about this new keybinding. This commit additionally: - Moves keybindings out of display.el and into keybindings.el - Conditionally sets KBDs if using work laptop
2020-02-11 12:00:24 +01:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Displays
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(when (device/work-laptop?)
(keybinding/exwm "<XF86Display>" #'display/cycle-display-states)
(general-define-key
:prefix "<SPC>"
:states '(normal)
"d0" #'display/disable-laptop
Centralize <SPC> in normal mode KBDs Merging keybinding and wpc-keybindings step-by-step...
2020-08-19 13:27:15 +02:00
"d1" #'display/enable-laptop
Support cycling through display configurations Today when I opened my laptop, I wasn't sure if it was powered off or on because the display was blank. Thankfully the volume was muted and the LED indicator was on, which informed me that the laptop was powered on. This saved me from unnecessarily rebooting. What happened was that last night I was working from home and using my external monitor. Usually I enable my external display and disable my laptop display. But when I left for work this morning, I unplugged the HDMI cable from my laptop without disabling the external display or enabling the laptop display. I noticed a XF86 button on my laptop entitled XF86Display. I figured that this could be a nice place to bind a key to toggle my laptop display on or off. At the last minute, I had the idea to just cycle through all possible display configurations that I use; there are only three anyways. When dealing with more than two states, I realized I should use a cycle to model the configuration states. Now I'm thinking that I should be using cycles to model toggles as well - instead of just using a top-level variable that I `setq` over. I haven't refactored existing toggles to be cycles, but I am excited about this new keybinding. This commit additionally: - Moves keybindings out of display.el and into keybindings.el - Conditionally sets KBDs if using work laptop
2020-02-11 12:00:24 +01:00
"D0" #'display/disable-4k
"D1" #'display/enable-4k))
Define notmuch KBDs Until I have more opinions about my workflow with notmuch, I will redefine the KBDs from Gmail that I'm comfortable with. While not many KBDs are defined here, evil-collection defines dozens, many of which I find reasonable; those that I disagree with, I've unbound in this commit. Composing emails in notmuch feels similar to writing a commit message with magit. I want to be able to type :x or :wq, but these commands don't DWIM. For magit, I'd like that behavior to be the same as `C-c C-c`; not surprisingly, for notmuch, I'd like the same. I've bound :x to do this for notmuch. I'd like to define a macro that can easily define buffer-local evil-ex commands for particular modes. This should lower the cost of defining evil-ex commands and hopefully convince me to support some of this desired behavior.
2020-02-14 16:38:28 +01:00
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; notmuch
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; evil-collection adds many KBDs to notmuch modes. Some of these I find
;; disruptive.
(general-define-key
:states '(normal)
:keymaps '(notmuch-show-mode-map)
"M-j" nil
"M-k" nil
"<C-S-iso-lefttab>" #'notmuch-show-previous-thread-show
"<C-tab>" #'notmuch-show-next-thread-show
"e" #'notmuch-show-archive-message-then-next-or-next-thread)
;; TODO(wpcarro): Consider moving this to a separate module
(defun evil-ex-define-cmd-local (cmd f)
"Define CMD to F locally to a buffer."
(unless (local-variable-p 'evil-ex-commands)
(setq-local evil-ex-commands (copy-alist evil-ex-commands)))
(evil-ex-define-cmd cmd f))
;; TODO(wpcarro): Support a macro that can easily define evil-ex commands for a
;; particular mode.
;; Consumption:
;; (evil-ex-for-mode 'notmuch-message-mode
;; "x" #'notmuch-mua-send-and-exit)
(add-hook 'notmuch-message-mode-hook
(lambda ()
(evil-ex-define-cmd-local "x" #'notmuch-mua-send-and-exit)))
;; For now, I'm mimmicking Gmail KBDs that I have memorized and enjoy
(general-define-key
Support KBDs for labelling emails I can already tag emails with `+` and `-`. Here I'm defining KBDs for moving messages from my inbox into: action, review, and waiting. I'm also mutually excluding messages in action, review, and waiting from inbox and vice versa. I'm also supporting a "muted" tag for now; I'm still learning how to use notmuch with email threads, but I'm hoping the "muted" tag will prevent future messages in a thread from arriving in my inbox.
2020-02-16 18:13:21 +01:00
:states '(normal visual)
Define notmuch KBDs Until I have more opinions about my workflow with notmuch, I will redefine the KBDs from Gmail that I'm comfortable with. While not many KBDs are defined here, evil-collection defines dozens, many of which I find reasonable; those that I disagree with, I've unbound in this commit. Composing emails in notmuch feels similar to writing a commit message with magit. I want to be able to type :x or :wq, but these commands don't DWIM. For magit, I'd like that behavior to be the same as `C-c C-c`; not surprisingly, for notmuch, I'd like the same. I've bound :x to do this for notmuch. I'd like to define a macro that can easily define buffer-local evil-ex commands for particular modes. This should lower the cost of defining evil-ex commands and hopefully convince me to support some of this desired behavior.
2020-02-14 16:38:28 +01:00
:keymaps '(notmuch-search-mode-map)
Support KBDs for labelling emails I can already tag emails with `+` and `-`. Here I'm defining KBDs for moving messages from my inbox into: action, review, and waiting. I'm also mutually excluding messages in action, review, and waiting from inbox and vice versa. I'm also supporting a "muted" tag for now; I'm still learning how to use notmuch with email threads, but I'm hoping the "muted" tag will prevent future messages in a thread from arriving in my inbox.
2020-02-16 18:13:21 +01:00
"M" (lambda ()
(interactive)
(notmuch-search-tag '("-inbox" "+muted")))
"mi" (lambda ()
(interactive)
(notmuch-search-tag '("+inbox" "-action" "-review" "-waiting" "-muted")))
"ma" (lambda ()
(interactive)
(notmuch-search-tag '("-inbox" "+action" "-review" "-waiting")))
"mr" (lambda ()
(interactive)
(notmuch-search-tag '("-inbox" "-action" "+review" "-waiting")))
"mw" (lambda ()
(interactive)
(notmuch-search-tag '("-inbox" "-action" "-review" "+waiting")))
Define notmuch KBDs Until I have more opinions about my workflow with notmuch, I will redefine the KBDs from Gmail that I'm comfortable with. While not many KBDs are defined here, evil-collection defines dozens, many of which I find reasonable; those that I disagree with, I've unbound in this commit. Composing emails in notmuch feels similar to writing a commit message with magit. I want to be able to type :x or :wq, but these commands don't DWIM. For magit, I'd like that behavior to be the same as `C-c C-c`; not surprisingly, for notmuch, I'd like the same. I've bound :x to do this for notmuch. I'd like to define a macro that can easily define buffer-local evil-ex commands for particular modes. This should lower the cost of defining evil-ex commands and hopefully convince me to support some of this desired behavior.
2020-02-14 16:38:28 +01:00
"e" #'notmuch-search-archive-thread)
Debug failed initialization of keybindings Some more pains of weening off of Dropbox is that my Emacs initialization is sensitive to dependencies and missing require statements. I'm still debugging everything. Some modules called `exwm-input-set-key` before the `window-manager` module loaded, which itself requires EXWM. This broke initialization. To get around this I could've called `(require 'exwm)` in each of those modules. I chose to define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm not sure if this is the best way forward, but it is *some* way forward.
2020-01-18 23:47:11 +01:00
(provide 'keybindings)
;;; keybindings.el ends here
Reference in a new issue Copy permalink