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.
Before I switched to vterm.el, I used alacritty as my primary terminal.
I could not install alacritty on gLinux, so I switched to terminator.
When I was ricing my machine, I wanted my Emacs theme to change my
terminator theme. I never finished that project, and it is quite dusty
now.
When I run `nix-env -f '<briefcase>' -iA emacs`, Nix builds a derivation of
wpcarros-emacs using the path to the Emacs derivation. This doesn't work well on
glinux and causes strange behavior. For instance, Chrome crashes when it tries
to browse for files. Building with `nix-env -iA emacs.glinux` fixes this and
other problems.
Miscellaneous other changes:
- Remove unnecessary fix-point recursion
- Drop support for unused dottime.el
- Remove unused overrideEmacs
- Remove unused withLocalConfig
- Support emacs.glinux and emacs.nixos alternative derivations
TL;DR:
- Prune unused themes
- Prefer "JetBrainsMono" font for all themes
- Remove TODOs that I've either supported or that I'm uninterested in supporting
I'm working off of my laptop but I'm using my 4k monitor. The expression that
sets `fonts/size` could be more sophisticated and detect this, but for now, I'm
just bumping up the size.
When I first switched to EXWM, I wrote a lot of Elisp. I think I was mostly
excited about having a monorepo and, as I had a backlog of ideas that I wanted
to implement, I ended up writing many halfly baked ideas in Elisp. These are
mostly sketches.
Problem:
prettier-js waits for rjsx-mode. rjsx-mode only runs on .js files. As such,
the hook that installs prettier-js-mode for *all* of my frontend hooks, which
includes more than just js files, does not install until a javascript file is
opened.
Solution:
Do not conditionally load prettier-js.
Bonus:
Remove the .js mode from rjsx.
I think I removed the `(server-start)` call when I was debugging some EXWM
issues. I have stabilized my configuration considerably since then, and I'd like
to use the Emacs server.
I'm currently setting NIX_PATH in ~/briefcase/shell.nix. This means when I call
`nix/rebuild-emacs` from a buffer that is inside the briefcase directory, the
command succeeds because NIX_PATH is properly defined. When I call
`nix/rebuild-emacs` from any other location it fails.
I'm hard-coding the NIX_PATH in this command so that I can call
`nix/rebuild-emacs` from any buffer that is currently active.
Support commonly used programs like fd, exa, bat, etc.
For now, I'm unsure how to manage the programs in my emacs/default.nix with my
home.nix. I'll wait until I have a stronger opinion to handle this.
I'm not sure if this commit breaks everything in my monorepo. I think it
will.
Why am I doing this? Perhaps it's a bad idea. I don't fully understand how
readTree works. My ignorance is costing me hours of time spent debugging. In an
effort to better understand readTree, I'm removing the default values for my Nix
expression parameters, which I believe have preventing errors from surfacing.
- Support command to open a dired buffer with wpcarro's $HOME directory for any
host defined in ssh/hosts.
- Support opening the current buffer with sudo privileges.
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.
