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.
Until now my notmuch is usable but not almost always pleasurably so. For
example, when I reply to messages, notmuch warns that "Insert failed:"; when I
check Gmail, the reply sent... strange. After consulting with a fellow notmuch
user and Emacs disciple, tazjin@, I borrowed some of his notmuch configuration.
- notmuch is no longer warning about replies
- Replies do not include noisy email signatures
- I have an Emacs User-Agent header in my outgoing mail
- All of this and more...
Add tag:unread to:
- direct
- broadcast
- systems
Additionally: I added "and not tag:sent" for direct because oftentimes I send
myself mail. Without that condition, my sent mail shows up in direct.
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!
Today I setup declarative gmail filters using some Google internal tooling. I'm
now adding labels to messages from Critique, Sphinx, Ganpati, "The Daily
Insider", messages sent directly to me, and more. These labels are applied
server-side.
On the notmuch, client-side, I'm support saved queries for these newly created
gmail labels.
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.
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.
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
Without these KBDs, C-k kills buffers. As an evil-mode user, I expect C-k to
move upwards. As such, adding the `ivy-switch-buffer-map` to my existing ivy
KBDs that handle a similar use-case.
Note: I'm unsure why the KBDs in evil-collection didn't cover this.
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.
Supporting these functions was a little tricky. For example, how should we
handle calling cycle/remove on the item that is currently focused? After
attempting to be clever, I decided to just set the value to nil and let the
consumer decide what is best for them. I can always support a more opinionated
version that fallsback to previous-index if previous-index is set. But until I
have a better idea of how I'm going to consume this, I think nil is the best
option.
Add predicate for determining if a cycle contains items.
Updated cycle/{new,from-list} to support setting current-index to nil when a
consumer calls it with an empty list.
I'm in the midst of transitioning onto a few new tools.
My previous workflow just used `nix-env` to install *some* packages. I didn't
have a prescribed methodology for which packages I would install using `nix-env`
and which ones I would install using `sudo apt-get install`. Sometimes if a
package would be available in my aptitude repositories, I'd use that; other
times when it wasn't available I'd use `nix-env`. One complication about being
on gLinux intead of NixOS is that some packages (e.g. nixpkgs.terminator) is
available via `nix-env -iA nixpkgs.terminator`, but the installation won't
actually run on my gLinux. In these instances, I would install terminator from
the aptitude repositories.
Then @tazjin introduced me to his Emacs configuration that he builds using
Nix. What appealed to me about his built Emacs is that it worked as expected on
either a NixOS machine and on gLinux (and presumably on other non-NixOS machines
as well).
A setup towards which I'm working is to own one or a few NixOS machines whose
configurations are entirely managed with Nix. On devices like my work machines,
which cannot run NixOS, I can build as much of the software that I need using
Nix and attempt to minimize the ad hoc configuration either with shell scripts,
python, golang, or more Nix code... it's clear that I still don't have a clear
idea of how that part will work.
For now, I'm adopting nix, nix-env, lorri, direnv, and weening off of aptitude
as much as I can. Things are a bit messy, but my general trend feels
positive. Stay tuned for more updates.
- Prefer goimports to gofmt. goimports calls gofmt; it also adds and removes
dependencies.
- Assert the presence of goimports, godoc, godef
- KBD godef to M-.
- Support the M-x compile command for calling `go build -v`
I mistakenly mapped one of my dual-function keys on my Ergodox to send Shift+CMD
instead of CMD. When some of my Emacs keybindings weren't firing, I noticed that
the key event they received was some like `C-S-s-<char>` instead of say
`C-s-<char>`. As a quick fix, I duplicated each of my keybindings that relied on
the CMD key to support Shift+CMD as well until I remapped the key on my
Ergodox. This morning, I remapped the Shift+CMD key to CMD, so I'm bidding adieu
to this code.
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.
Currently, after I connect my monitor to my laptop, I run `display/enable-4k`,
which will use `xrandr` to enable the display. The scaling of the enabled
display is not what I expect. So I've habituated re-running the same function,
`display/enable-4k`, which scales the display and meets my expectations.
What's strange is that if instead of running `display/enable-4k` the first time
from Emacs, I call `xrandr ...` from a terminal, this enables the display and
scales it properly on the first invocation.
I'm unsure how to explain this behavior. It's possible that a environment
variable is set properly in the terminal that isn't set in my Emacs, but this is
just a guess.
I'm going to using a different invocation in display.el that explicitly passes
the monitors dimensions. Let's see if that works.
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.
Renaming my mono-repo briefcase.
I first introduced this commit in master, but it introduced a bug where one of
two things would happen:
1. Emacs wouldn't start and would crash X.
2. Emacs would start but my keyboard wouldn't work.
I learned some valuable debugging skills in the process. Here are some of them:
When my keyboard was broken, I wanted to control my computer using my
laptop. Thankfully this is possible by using `x2x`, which forward X events from
the SSH client to the SSH host.
```shell
> # I'm unsure if this is the *exact* command
> ssh -X desktop x2x -west :0.0
```
Git commit-local bisecting. I didn't need to do a `git bisect` because I knew
which commit introduced the bug; it was HEAD, master. But -- as you can see from
the size of this commit -- there are many changes involved. I wanted to binary
search through the changes, so I did the following workflow using `magit`:
- git reset --soft HEAD^
- git stash 1/2 of the files changed
- re-run `nix-env -f ~/briefcase/emacs -i`
- restart X session
- If the problem persists, the bug exists in the non-stashed files. Repeat the
process until you find the bug.
In my case, the bug was pretty benign. Calling `(exwm/switch "Dotfiles")` at the
bottom of `window-manager.el` was failing because "Dotfiles" is the name of a
non-existent workspace; it should've been `(exwm/switch "Briefcase")`.
There may have been more problems. I changed a few other things along the way,
including exposing the env vars BRIEFCASE to `wpcarros-emacs` inside of
`emacs/default.nix`.
The important part is that this was a valuable learning opportunity, and I'm
glad that I'm walking away from the two days of "lost productivity" feeling
actually productive.
