Instead of three separate `general-define-key` statements consolidate all
three. I'm not sure I was aware of this feature of general when I originally
defined all three keybindings.
The `prelude/assert` for the existence of the `opam-install` directory was
failing.
I believe this assertion would have been failing sooner, but a bug in my
initialization was preventing Emacs from evaluating `wpc-ocaml.el`. It seems
that I removed whatever was jamming the initialization and as such, I uncovered
some more bugs.
Let this serve as a reminder that just because it hasn't bitten you yet, doesn't
mean that your software doesn't have a bug.
Preferring to use the `general` package for defining leader-prefixed keybindings
than `evil-leader`.
This TODO has existed for quite awhile, so I'm pleased to finish it!
During the cleanup, I deleted some keybindings that I no longer used.
When Emacs starts it's called from xsessionrc.shared, which is called outside of
direnv's .envrc scope. Because of this variables defined therein, like
ORG_DIRECTORY, are undefined and prevent Emacs from initializing.
I'm hard-coding the `org-directory` variable for now and removing references to
`(getenv "ORG_DIRECTORY")`.
After moving some environment variables out of `~/.profile` and into a `.envrc`
file, I broke some of my modules because Emacs, which is started in
`~/.xsessionrc.shared`, is started from outside of the `.envrc` scope.
Thankfully someone wrote an excellent Emacs integration with `direnv` so now the
world keeps turning and it is even more beautiful than it was previously.
Many times when I run `prism-mode` the contrast between the colors isn't strong
enough. This is unfortunate because I really like the idea.
Perhaps one day I can submit a PR to ensure that it uses the highest-contrast
colors available to it.
Instead of keeping this in my ~/.profile, I'm going to define it in .envrc.
What I still don't know is how functions like `getenv` are supposed to interact
with direnv. I suppose maybe they aren't? Right now, when I call
`(getenv "DOTFILES")` from Emacs, it's `nil`, which I understand. Hopefully the
more I use direnv, the more reasonable expectations I'll have.
Since I moved this repository away from Dropbox, my elpa, melpa, quelpa packages
weren't automatically syncing. This crutch, once removed, cause my Emacs
initialization to fall-over.
This commit patches some of those missing dependencies.
I'm also making this my default theme for now. I'm growing a bit tired of
randomly assigning themes, since my `terminator` theme is not coupled to my
Emacs theme.
I temporarily set it to /tmp/custom.el while I was in the midst of Nixifying my
Emacs setup. Since I'm not Nixified at the moment, I'm reverting this, so that
Emacs doesn't ask me the same questions about loading themes every day.
Configuring deadgrep to do a number of things:
1. Set `deadgrep--context` to see more context "after" in the output.
2. Define `deadgrep/dwim` to use a region if one is present; otherwise just
behave as `deadgrep`.
Warning: This commit relies on a patch I made to deadgrep: supporting the
`deadgrep--additional-flags`.
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'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.
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`
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.
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!
After some back-and-forth, I'm trialing fish shell instead of zsh as my default
shell. For now, I'm porting the aliases.zsh into config.fish -- defining them as
abbreviations instead of aliases; this preference may change. See the commentary
in config.fish for more information.
A spent a lot of time in zsh and built much configuration, so supporting fish
may take considerable time. Here's some work that remains:
TODO:
- Port functions.zsh
- Port variables.zsh
- Port zle.zsh
Currently paying the price of months of non-diligent git usage.
Here's what has changed.
- Theming support in Gvcci and wpgtk
- Dropping support for i3
- Supporting EXWM
- Many Elisp modules
- Collapsed redundant directories in ./configs
