I've wanted an MRU/LRU sort of my "source code buffers" in Emacs. This commit
support three ways for working with a cache of source code buffers.
So first, what's a source code buffer? Well it isn't a buffer like *Messages*;
we can call these "Emacs-generated" buffers for convenience. Other problematic
buffers are buffers like `magit-status` and `dired-mode` and `erc` buffers.
I added some predicates for querying buffers for their major modes.
Supporting three KBDs for quickly accessing these functions:
1. <SPC><SPC> Toggle previous buffer
2. <SPC>b Use ivy to fuzzily search source code buffers
3. C-{f,b} Cycle {forwards,backwards} through the source code buffer cache.
I had forgotten that I defined <SPC>J. Maybe I should switch to using Hydras or
transient mode to improve the discoverability of my own setup... well in the
spirit of support things that I will likely forget, here's a new KBD for editing
config files in the `~/.config` directory.
Defined `dotfiles/find-emacs-file` and `org-helpers/find-file`, to clean up some
of the `find-file` calls I have with long path names. This DRYs things up as
well so that the path can be changed without breaking many other things.
I've wanted a library like this ever since I saw Douglas Crockford's JS talk
about scope highlighting as a more useful alternative to syntax highlighting.
I attempted to Nixify my Emacs over winter break. I made some meaningful
progress, but not enough progress to use my Nixified Emacs setup. Since Emacs is
my primary editor and my window manager at work and at home, having a partially
baked setup is untenable at the moment.
Reverting these changes so that I can get on with my work, but checking them in
so that I can pick up where I left off one day.
The things that I dislike about this setup are:
1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only
version of the source code, so I cannot edit it, which doesn't feel lispy.
2. I need to rebuild the derivation when I change something, which also doesn't
feel lispy.
There are ways to circumvent both of these drawbacks, but for now, I'm checking
this in only to later revert it.
After deciding to support the `C-s-` prefix for lispyville KBDs, I'm
re-introducing support for:
- `lispyville-drag-backward`
- `lispyville-drag-forward`
- `lispyville-end-of-defun`
- `lispyville-beginning-of-defun`
Previously my ERC setup just supported Google's internal IRC. Now I have
Freenode for things like #nixos, #emacs.
This complicated my KBDs for cycling through IRC channels since certain channels
only exist on certain servers. To remedy this, I introduced a temporary solution
that looks up the server given a particular channel. This isn't ideal, but it
works for now.
If you refer to the previous commit where I change shell-command usages to
start-process function calls, you'll see the rationale for why I prefer
start-process.
This commit introduces a more ergonomic API for start-process that fits most of
my current use-cases of it. This cleans up the code. I have introduced a bug in
the way that I'm tokenizing the COMMAND value. I've tracked that with a
TODO. For now it only affects the `xmodmap -e '<command-string>'` calls, which
isn't too disruptive.
Continuing the series of easy-win commits that increase the speed of commands
that I was previously using `shell-command` to run by using `start-process`
instead.
As promised in the previous commit, I'm refactoring usages of `shell-command` to
prefer the faster alternative `start-process`. So far, I'm pleased with the
results.
Without doing any benchmarking (break this naughty habit), I'm preferring to
call `start-process` instead of `shell-command` in my `wallpaper/set`
function. I noticed that the `shell-command` call was unnecessarily polluting my
`pstree` call when I debugging my randomly changing wallpaper bug.
I'm mostly likely going to change a few more `shell-command` calls to prefer
`start-process`.
While I first switched to EXWM warily and thinking it would only be temporary,
it seems like this switch is here to stay. It turns out that EXWM was exactly
the integration I've been looking for. How serendipitous it that I found it when
I did.
Thank you, @tazjin.
While this commit isn't much (i.e. notmuch), it represents one brave step
forward in the quest for supporting email in Emacs -- something I'm estimating
to be somewhere between a 1.5x and 2x workflow booster.
TL;DR:
Problem: I ran into a bug where my computer wallpaper was changing every five
seconds whenever my init.el file was open and I was typing in it.
Short-term solution: Disable flycheck.
Long-term solution: Disable flycheck just for Elisp or just for init.el in
Elisp.
Post Mortem:
Warning: If you have flycheck-emacs-lisp-initialize-packages set to auto or
really anything other than nil, than the emacs-lisp flycheck-checker will spin
up a new Emacs instance, and evaluate all of the Elisp in init.el.
Why does this matter? Well, if like me, you have code anywhere in your
init.el (and any files downstream from init.el), that code will get evaluated
not just twice. But countless times... tens, hundreds, w/e. So... while you
might think you have code that is just running at startup this code will be
called incessantly.
As a dramatic, contrived example, if you had something like...
```elisp
(bank/send :amount 100 :to "wpcarro@gmail.com")
```
...anywhere in that your init.el would evaluate, you may end up sending
wpcarro@gmail.com millions of dollars. To make debugging this problem a bit more
complicated is that because this runs in a separate Emacs instance, you can't do
something like...
```elisp
(defvar already-evaluated? nil)
(unless already-evaluated? (bank/send :amount 100 :to "wpcarro@gmail.com"))
(setq already-evaluated? t)
```
...since the `already-evaluated?` variable will be local to the Emacs
instance. So if you needed a mechanism to ensure code like this runs only once,
you would need a way to share this semaphore across Emacs instances --
e.g. writing to and reading from disk.
I'm sure that there is a fish package that supports git aliases or
abbreviations. This time, I'm preferring to write my own.
Side note: The more that I use fish's abbreviations, the less that I like them
-- at least for the way in which I'm using them.
I'm not actually sure if this is sensitive information, but I'm erring on the
side of caution and ignoring it in case it is.
squash! Ignore .gnupg/random_seed
Google-related files should eventually be moved out of GitHub hosting and onto
Google infrastructure (e.g. Git on Borg).
When I do this, I should run:
```fish
> git grep --ignore-case google (git rev-list --all)
```
To assess the reference I've introduced into this repository.
Other tools that should come in handy when I do this are:
- git filter-branch
- BFG repo-cleaner
For now, my lack of understanding of purpose results in purpose getting in my
way. One day, I may reinvestigate this. For now, I'm attempting to learn Prolog
and Nix, which is occupying most of my tolerance for new technology.
It took me awhile to install evil-magit because I believed that evil-collection
supported it. My grasp of Emacs bindings was enough to tolerate the strangely
"inconsistent" KBD support of in magit. Eventually though my tolerance waned,
and I verified that evil-collection does *not* support magit, and suggests that
users seek evil-magit. I did that. I do not regret it.
Installing Wilfred's refine.el, which is a lovely package for interactively
editing data structures. Go LISP!
Support functions for ensuring the existence of directories and files. These
functions represent the type of small ergonomic wins that I believe libraries
should support.
In a moment of strong opinions against variadic functions, I defined
maybe/somes? and redefined maybe/some? to be non-variadic. I'm not sure if I
feel as strongly about that change as I did when I made it. Either way, the
change remains and math.el is broken unless it consumes maybe/somes?, so... this
does that!
I provided the wrong usage example in my documentation. This goes to show how
critical generated documentation is to the goal of documentation reliability,
which itself bolsters the goal of documentation in general.
TODO: It may be preferable to augment my git history to remove the traces of
these files ever existing. For now, since I value a precise git history over a
pristine git history and my tendancy to maintain the former is sometimes at odds
with my goal of the latter, I'm saving this work for a later date.
