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")`.
Point the constants/current-project variable to my mono-repo.
The constants.el file isn't as populated as I was expecting and I think
supporting it introduces indirection in my code. I'm considering removing it.
Some more pains of weening off of Dropbox is that my Emacs initialization is
sensitive to dependencies and missing require statements. I'm still debugging
everything.
Some modules called `exwm-input-set-key` before the `window-manager` module
loaded, which itself requires EXWM. This broke initialization. To get around
this I could've called `(require 'exwm)` in each of those modules. I chose to
define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm
not sure if this is the best way forward, but it is *some* way forward.
Since the tokenizing isn't working as expected, my keyboard.el function
keyboard/swap-caps-lock-and-escape was silenting failing.
I'm adding a prelude/refute in that function to make the failures noisy until
the tokenizing is properly supported.
Move `wpc/find-file-split` directly below `wpc/find-file`.
TODO: This module is quite old and served as a bit of a dumping grounds for me
for a long time. As such, I think I should consider deleting dead code and
moving some of these functions to other modules.
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.
After defining the scrot.el module, I don't have much use for this function. In
fairness, I never used this function too much; I wrote it early on when I first
switched from i3 to EXWM. As such, it's a bit sloppy. Happy whenever I get a
change to do some spring cleaning.
Write some Elisp to work with `scrot`, Linux's CLI utility for taking
screenshots. It's been too long this that was working as expected!
As a bonus, I learned that it's possible to copy images to Linux's clipboard and
not just their file paths. This makes for a really nice UX!
TL;DR: Preparing ivy-clipmenu for publishing.
Also:
- Removes lingering TODO items.
- Clarifies module and function documentation.
- Defines groups for custom variables.
- Supports history variable for ivy-read.
clipmenu/list-clips previously didn't sort or deduplicate entries in the same
way that the existing clipmenu list_clips function did. After running some
tests, clipmenu/list-clips matches the output except I'm unsure my duplicate
algorithm is identical.
It seems like something when I run `display/enable-4k` my resolution isn't at 4k
fully. However, when I call the same command on the command line it does scale
properly. This doesn't sound likely, and frankly I haven't had too much time to
try and reproduce this. Hence - the TODO!
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.
This function was causing problems with my Emacs. For example, when I ran
`wpc/find-file`, which is bound <leader>f and a KBD that I call frequently, the
internals would startup fish with my configuration file. Then `nix_find
autojump` would fail and the entire command would error. To make things worse,
the error was a bit opaque.
TODO: Why do certain commands `counsel-projectile-find-file` startup fish and
load my configuration file? I'd prefer it used something like bash and didn't
attempt to load a configuration file since that would most likely slow things
down.
