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.
Wrapping the `nix eval` incantation in a fish function for two reasons:
1. Document that this is how to evaluate Nix from a file.
2. Provide a more ergonomic way of evaluating Nix from a file.
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.
The previous commit that adds Java code is part of a larger project intended to
use Nix to package Clojure. I'd like to build something similar to @tazjin's
buildLisp except for Clojure instead of for Common Lisp. Once building for both
ecosystems is similarly easy, it will be easier for me to compare the two
languages. Right now `buildLisp` is so good that it attracts me to Common Lisp
even when I don't know the language.
Add an example of two java files, Main.java and Another.java, where Main.java
depends on Another.java. This is part of a larger example of attempting to use
Nix to package these.
Also ignoring the *.class files that `javac <filename>` outputs.
Removing the default.nix that I used to attempt to build prove, a Common Lisp
unit testing library. Also removing the lisp module with the unit tests
themselves.
`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.
After some toil, I have a working proof-of-concept blog. The idea is simple:
write blog posts in markdown and store the posts in the `./posts`
directory. Then use the server and `pandoc` to convert these markdown files into
HTML at request time. I'm using nix to package everything together. It's far
from perfect, but it works at the moment, which is encouraging.
All of this is still a work-in-progress. Just checking in my work.
Also:
- Write function `render-post` to convert a markdown file into HTML. This is
still a work-in-progress since we need to capture the output and not just have
it printed to *standard-out*.
- Return dummy data in /posts
- We need the markdown files, to be in the /nix/store and the server needs to be
aware of there location.
- Since we're dependending on `pandoc`, our server needs to know about it too.
For both of these cases -- especially for the latter case -- I imagine there may
be a more idiomatic way of doing this.
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.
