Update code that depends on my mono-repo being named "mono". I've renamed it to
"universe", which explains the changes in this commit.
TODO: Merge dotfiles into universe.
I'm having trouble debugging why `pgrep emacs` returns two PIDs instead of just
one. Additionally when I call `emacsclient .` on the command line, I see a
message...
"Waiting for Emacs..."
...but when I cycle through all of my workspaces, I don't see any active
buffers. This commit is part of a larger debugging effort to get this working as
expected.
The end goal is to have some functions that help me manage my Monzo and YNAB
accounts. YNAB (i.e. youneedabudget.com) doesn't support Monzo
integrations. However, both services offer APIs. Here I'm sketching ideas for
what the API integrations might look like. Coming soon: monzo.el.
Not adding it as a top-level dependency since maybe.el depends on on
prelude.el. This shouldn't be a circular dependency when the requirement happens
in the function's scope though.
Remove `dbus-launch` and prefer simply `exec emacs`. Add `--no-site-file` and
`--no-site-lisp` flags.
Temporarily disable `google-stuff.el` because it's unavailable with the
`--no-site-lisp` flag.
This should all be fixed when I fully nixify my Emacs.
Why?
- `company-mode` is too noisy in IRC buffers.
- `auto-fill-mode` inserts newline characters that end up each being their own
message, which means that I make more noise than I should in IRC.
This takes care of my outstanding TODO of understanding why something ivy was
being used and other times it wasn't. It turns out that there is a generic
`completing-read` function that many Emacs packages consume. `ivy-mode` ensures
that when that function is called it is used instead of the default Emacs
completing package.
I'm still unsure of the difference between ivy and counsel. My best guess
currently is that counsel is the narrowing framework and ivy is the integration
of the narrowing framework with `completing-read`. Swiper must be the
integration with incremental {forward,backward} search.
`dired-display-file` opens the file in another window but does not focus that
window. `dired-find-file-other-window` does what `dired-display-file` does
except it focuses that window.
This function builds a version of SBCL using `nix.buildLisp` and points `sly` to
the built executable. The result is a REPL with access to your project's
dependencies, which is quite useful. One drawback at the moment is that if new
dependencies are added to the project, I think I need to rebuild SBCL using nix
and restart sly.
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.
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.
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")`.
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.
