While it's probably a good idea to assign epics to new stories,
depending on the methodology used by the team not everything may
warrant being attached to an epic. E.g. one off task and what
not.
Attempting to write a blog where:
- The server is Common Lisp. Why? I'd like to learn Common Lisp.
- The blog posts can be written in Markdown.
- The package is developed and deployed using Nix.
Most of this is a learning exercise. The blog itself is something that I'd like
to use instead of Medium and other forums.
Create a third_party subdirectory and a third_party/lisp. This directory layout
resembles and is inspired by the layout of Google's mono-repo, Google3. @tazjin
borrowed this idea from Google and I'm borrowing the idea from him.
Using @tazjin's depot/default.nix to bootstrap this project. I'll be borrowing
his Nix idioms until I better understand Nix and have preferences of my own.
Since I spend a decent amount of time scouring the excellent work of my
colleague, @tazjin, I figured having some functions and KBDs setup to make this
work cheaper would be beneficial.
Also preferring the name `"depot"` to `"tazjins-depot"`. I don't think the
namespace `"tazjin-"` is useful at this time. I'm considering renaming my
mono-repo `"universe"`... a bit grandiose, but hey, let me get my kicks.
I'd like to limit the available snippets to those snippets that I have
explicitly defined. I ran into this problem when defining the `defpackage`
snippet for `lisp-mode`; it appeared that another snippet for `defpackage`
existed somewhere on my machine.
Since I'm new to the CL world, snippets are a useful note-taking analogue with
the added benefit of potentially speeding up my workflow should the
muscle-memory set.
My first foray trying to package Common Lisp with Nix. I'm using @tazjin's
buildLisp and other libraries, all of which I'm importing as `tpkgs`, and all of
which have been a tremendous boon to my productivity.
One of my Google Emacs libraries depends on the `magit-popup` library. I believe
it's `fig-status` and I'm unsure why that library didn't ship with
`magit-popup`... tune in next week for more packaging woes.
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.
I recall making these changes days ago, but I cannot seem to find any evidence
of those changes.
Extending the lifetimes of GPG cache to improve the UX of using `pass` and
similar tools.
After some confusion about my `emacsclient` is currently working as
expected. Perhaps it always did. I had `emacs --daemon` in my
`~/.xsessionrc.shared` for awhile, which may have confused
`emacsclient`. Whatever happened, I'm glad it's working now.
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.
I'm trying a mouse-less workflow supported by `keynav`. So far, everything works
pretty well... and then I needed to take a screenshot and I don't know how to
use `scrot --select` without a mouse.
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.
