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.
After a few weeks of having this idea in the back of my mind, I began supporting
an ivy interface to clipmenu. I tried clipmon.el for awhile, but it wasn't as
good as clipmenu in my experience. To get the best of both worlds, I'm
attempting to write an Emacs client for clipmenu! Stay tuned for more updates.
If I open source this, which I'd like to, I'll need to answer a few questions:
- How should I handle libraries like my prelude.el?
- How can I eject this from my mono-repo and dotfiles?
See the TODOs scattered throughout the module for an idea of the remaining
work. I'd estimate that there's about one to three more hours of work.
Create a finance module to help me cheaply calculate things like the future
value of a Spotify subscription or Dropbox subscription or Jiu Jitsu
membership.
I think when I was writing this, I needed a quick way to edit my dotfile's
README. I haven't used it since then, so in the interest of trimming fat, I'm
removing it.
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'm not sure I'm sold on the "D{0,1}" keybindings. The thought was that 0 would
indicate off and 1 would indicate on. This seems sensible to me. I'm hesitant
because I don't think I have precedent for this idiom in any of my existing
keybindings.
I'm also not sure I like these being leader-prefixed keybindings.
Calling `source` on `(direnv hook fish)` was creating startup problems with
fish. These problems leaked into a few of my Emacs file-searching commands as
well, which was pretty irritating for awhile. I'm still unsure of the
differences between `eval` and `source`. I'm moving on for now.
Two things:
1. I'm unsure if what I previously committed ever worked because the arguments
to `string/format` were flipped.
2. I'm unsure why my screen devices are sometimes eDP-1 and eDP1.
Perhaps expect more commits as this becomes more clear to me.
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`.
Instead of consuming `cycle/previous-focus`, define a function
`cycle/focus-previous!` that "focuses" the element at `previous-index` and
returns that element.
This function greatly simplified the code in window-manager.el and eliminated
the unnecessary `exwm/previous-workspace` variable that was managing the state.
Define a `cycle/previous-focus` function that returns the item that was
previously "focused" in the cycle. This is helpful for toggling back-and-forth
between buffers and EXWM workspaces for example without needing to define ad-hoc
variables to support it.
Also: Adds tests to cycle.el.
Also: Prefers `struct/set!` instead of `setf`. See the previous commit's message
for more information about that preference.
I originally tried using `struct/set` instead of `setf`, which I had forgotten
was the *immutable* version of `struct/set!`. When this didn't work, I reverted
to `setf`. After a good night's sleep and with a fresh set of eyes, I dug into
the issue and discovered that `struct/set!` was what I wanted the whole.
I am curious now about `struct/update` versus `struct/update!`; shouldn't the
former be immutable and the latter be mutable? I'll save that investigation for
a later date.
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.
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.
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
After attempting to package some of my Elisp libraries using Nix, I exposed
circular dependencies between modules that has existed for awhile.
I'm temporarily disabling this code since I do not have time to refactor
everything. When I get around to packaging everything, I'll need to resolve
these issues.
For now, I must carry on.
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
I had `tbz`, which toggles between a project directory and it's associated
blaze-bin.
I added three functions which support navigating to blaze-bin, blaze-genfiles,
and to the project root.
I'd like to regain control of my browsing bookmarks with a simpler solution
using `dmenu`, `i3`, and a text file.
TODO: drop support for Chrome bookmarks by porting all remaining bookmarks to
bookmarks.txt
NOTE: maybe change bookmarks.txt to bookmarks.json to support nesting. Could be
simply with `jq`.
Useful since helpful aliases and functions around creating sandboxed REPL
environments for languages like, Elixir, Haskell are on the way. Other languages
that might be interesting to support would be Clojure.
The `jshell` alias currently imports libs like guava and jOOL into the `jshell`,
which is nice for experimenting.
Experimenting with keeping some helpful `.jars` in `~/programming/jars`. This
may be a bad idea, and there may exist a more idiomatic way to do this instead
of wrapping `jshell` in an alias, but for now, I need to move on.
Also documents some abbreviations for applications. `jv` will be necessary so
that I don't conflict with `j` or `js` for javascript. Eventually I'll need to
be more organized to avoid naming collisions, but this is okay for now.
This allows me to take advantage of the --app=<URL> flag that google-chrome
supports, which is nice for a version of cider that bleeds all the way to the
window's edges. It makes Cider feel more like a native application experience.
This comes with the default configuration on i3. I removed this KBD originally
because I was hoping to use the $mod+{,Shift+}t KBDs frequently. I still do, but
as I get more comfortable with i3, splits, parent containers, etc. I may prefer
to create terminals this way. We'll see...
NOTE: consider migrating from GH private repo to Google's Git on Borg. This is
preferable since GH gets hacked and private repos can be exposed. While a path
to a Google 3 repo like SpeWall may not pose a large security risk, it certainly
isn't optimal. Imagine a path to a repository whose name leaked a secret
project. Two options:
1. embrace encryption options like Mozilla's `sops` and remain on GH private
2. switch wholesale from private GH to GoB
3. classify "sensitve" parts of dotfiles as such and move those to GoB and keep
everything else on private GH
One added perk of switching to GoB is saving the $7 monthly fee to support
private GH repos.
The nohup.out file was creating a bunch of noise and polluting my FS. It may
have been the correct thing to add, but if it was, I'm unsure why. Removing it
for now since it's been bothering me quite a bit.
Wraps the existing `prodaccess` executable and displays a quote from Google
ENG's fortune db.
Fortune is a GNU tool intended to support random quote compilation, display,
etc. It's pretty interesting.
NOTE: the `prodcertstatus` executable that this function is using as a guard
looks like it might be useful moving forward.
We already have `gcan`... looks like `gca` was already defined by some ZSH git
extension. This further weakens my dependency on that extension, which I think
is a good things.
May need to find a better KBD for `snip_it`, since I really enjoy Tmux's M-s to
switch sessions.
Learned about i3's "edge" concept. Re-supported KBDs for settings split
directions. Also adjusted theme colors.
Also adjusts the formatting of the timezone information to show GMT as LON, EST
as NYC, and Pacific as MTV.
I originally dropped support for these because I wanted to imitate OSX's
screenshot KBDs, which were mod+Shift+{3,4}. I'm not sure I want to imitate OSX
now that I don't have any Apple hardware besides my iPhone. I'm getting more
forgetting those KBDs. At the moment, however, I cannot find a better KBD for my
snip_it function. Stay tuned...
I must not have tested this before adding it to the repository; otherwise, I
would have found this. Oh well... it worked like a charm when copying the GPG
information from my desktop to my laptop.
In my quest to learn more about terminals, I added a function to output ten
emojis. Technically this tests the same thing as test_unicode.
Unfortunately I couldn't get `st` to output any colored emojis. This is a bit of
a buzzkill for my grand plans to create a terminal-based chat client that
supports emojis.
Defines functions for creating, deleting, renaming files.
Defines functions for encrypting/decrypting files.
Defines functions for archiving/unarchiving files.
Adds TODOs for wishlist items.
Adds `help` function to view `lf` documentation.
TODO: write generic explanation of desire to share KBDs between Emacs, Vim,
other programs that I can link to in documentation to avoid repeating myself.
I'm unsure if this is idiomatic POSIX shell scripting or not, but I generally
prefer function calls to variables. Thankfully things like Haskell don't
differentiate between the two. In other cold and hostile environments like shell
scripting, us programmers must take care to prefer functions to variables where
it makes sense.
If you're going to install things and support that with an aliases, might as
well support the removals of packages with an aliases. Better to keep systems
lean -- especially if entropy is the tendancy.
Separated i3/configuration since some of my devices support XFree86 keysyms
while others do not. This introduced some cascading changes.
- Removed ~/.config/i3/config from this repo. Since I will be switching between
devices semi-regularly and that file will be generated each time I switch to a
different device running an X session, I don't want the i3/config to spam my
`gst` and `gd` when I haven't changed configuration in either config.shared or
config.device.
- Update aliases, variables, etc. to point to config.shared instead of the
generated file.
- Ensure that X sessions generate the i3/config file.
- Ensure that i3 reload and restart command generate the i3/config file.
