As I mentioned in the previous commit, I now use vterm.el as my primary
terminal. I wrote most of this Elisp when I first started using Emacs. I
know longer need it.
Every Tuesday I work from Google's 6PS office instead of BEL. I work from my
laptop, which often requires that I ssh into the desktop work station in BEL. I
have settled on a locally optimal workflow that I'd like to improve. To help
seek higher ground, I'm planning on using ssh.el to configure tramp and define
utility functions to lower my cost of exploring new workflows.
- Defines a function, `ssh/desktop-cd-home` that helps me quickly open a dired
buffer for my work station's home directory.
- Documents some variables that I set weeks ago.
- Requires ssh.el in init.el.
keybindings.el calls (require 'evil-ex), which I introduced in this commit...
0456a1c4b4
...calling (require 'evil-ex) loads evil. When evil is loaded before
evil-want-integration is set to nil, evil-collection writes to *Warnings* when
Emacs initializes, which I find noisy. This commit ensures the
evil-want-integration is set to nil before evil is loaded, which appeases
evil-collection and thus removes the warning message.
Bonus:
If you git checkout the previous commit, and attempt to run the KBDs...
- `SPC g s`: magit-status
- `s h`: evil-window-vsplit
...from a buffer whose major-mode is dired-mode, you should notice that the
above functions won't execute.
Strangely though, if you look at this commit...
37f8ca04f2
...I fixed these issues. Well I introduced a regression when I added 0456a1c.
My current guess is that when evil-collection complains about
evil-want-integration, it is breaking the evaluation sequence of my init.el
file. wpc-dired.el is downstream from wpc-keybindings.el, which requires
evil-collection. Perhaps no modules required after wpc-keybindings.el are
evaluated after evil-collection warns about evil-want-integration. Even if that
assumption is wrong, what I do know is that this commit fixes the
evil-collection warning and restores the KBDs for dired-mode-map.
Here's to feeding two birds with one scone!
I decided to start writing go code for scripts instead of python. I think this
will be a learning opportunity for me and should increase the integrity of my
scripts by adding some static type checking.
