Supporting these functions was a little tricky. For example, how should we
handle calling cycle/remove on the item that is currently focused? After
attempting to be clever, I decided to just set the value to nil and let the
consumer decide what is best for them. I can always support a more opinionated
version that fallsback to previous-index if previous-index is set. But until I
have a better idea of how I'm going to consume this, I think nil is the best
option.
Add predicate for determining if a cycle contains items.
Updated cycle/{new,from-list} to support setting current-index to nil when a
consumer calls it with an empty list.
I removed most of the packages that I install with `nix-env`. You can view these
with `nix-env --query`. This is one small step in a grander project to migrate
entirely to a declarative config managed by Nix.
I'm in the midst of transitioning onto a few new tools.
My previous workflow just used `nix-env` to install *some* packages. I didn't
have a prescribed methodology for which packages I would install using `nix-env`
and which ones I would install using `sudo apt-get install`. Sometimes if a
package would be available in my aptitude repositories, I'd use that; other
times when it wasn't available I'd use `nix-env`. One complication about being
on gLinux intead of NixOS is that some packages (e.g. nixpkgs.terminator) is
available via `nix-env -iA nixpkgs.terminator`, but the installation won't
actually run on my gLinux. In these instances, I would install terminator from
the aptitude repositories.
Then @tazjin introduced me to his Emacs configuration that he builds using
Nix. What appealed to me about his built Emacs is that it worked as expected on
either a NixOS machine and on gLinux (and presumably on other non-NixOS machines
as well).
A setup towards which I'm working is to own one or a few NixOS machines whose
configurations are entirely managed with Nix. On devices like my work machines,
which cannot run NixOS, I can build as much of the software that I need using
Nix and attempt to minimize the ad hoc configuration either with shell scripts,
python, golang, or more Nix code... it's clear that I still don't have a clear
idea of how that part will work.
For now, I'm adopting nix, nix-env, lorri, direnv, and weening off of aptitude
as much as I can. Things are a bit messy, but my general trend feels
positive. Stay tuned for more updates.
- Prefer goimports to gofmt. goimports calls gofmt; it also adds and removes
dependencies.
- Assert the presence of goimports, godoc, godef
- KBD godef to M-.
- Support the M-x compile command for calling `go build -v`
I mistakenly mapped one of my dual-function keys on my Ergodox to send Shift+CMD
instead of CMD. When some of my Emacs keybindings weren't firing, I noticed that
the key event they received was some like `C-S-s-<char>` instead of say
`C-s-<char>`. As a quick fix, I duplicated each of my keybindings that relied on
the CMD key to support Shift+CMD as well until I remapped the key on my
Ergodox. This morning, I remapped the Shift+CMD key to CMD, so I'm bidding adieu
to this code.
Press `<M-escape.` to display a list of buffers hosting X applications. Use
`completing-read` to select and focus one of these.
See the function docs and TODOs for more information.
Currently, after I connect my monitor to my laptop, I run `display/enable-4k`,
which will use `xrandr` to enable the display. The scaling of the enabled
display is not what I expect. So I've habituated re-running the same function,
`display/enable-4k`, which scales the display and meets my expectations.
What's strange is that if instead of running `display/enable-4k` the first time
from Emacs, I call `xrandr ...` from a terminal, this enables the display and
scales it properly on the first invocation.
I'm unsure how to explain this behavior. It's possible that a environment
variable is set properly in the terminal that isn't set in my Emacs, but this is
just a guess.
I'm going to using a different invocation in display.el that explicitly passes
the monitors dimensions. Let's see if that works.
I decided to start writing go code for scripts instead of python. I think this
will be a learning opportunity for me and should increase the integrity of my
scripts by adding some static type checking.
Renaming my mono-repo briefcase.
I first introduced this commit in master, but it introduced a bug where one of
two things would happen:
1. Emacs wouldn't start and would crash X.
2. Emacs would start but my keyboard wouldn't work.
I learned some valuable debugging skills in the process. Here are some of them:
When my keyboard was broken, I wanted to control my computer using my
laptop. Thankfully this is possible by using `x2x`, which forward X events from
the SSH client to the SSH host.
```shell
> # I'm unsure if this is the *exact* command
> ssh -X desktop x2x -west :0.0
```
Git commit-local bisecting. I didn't need to do a `git bisect` because I knew
which commit introduced the bug; it was HEAD, master. But -- as you can see from
the size of this commit -- there are many changes involved. I wanted to binary
search through the changes, so I did the following workflow using `magit`:
- git reset --soft HEAD^
- git stash 1/2 of the files changed
- re-run `nix-env -f ~/briefcase/emacs -i`
- restart X session
- If the problem persists, the bug exists in the non-stashed files. Repeat the
process until you find the bug.
In my case, the bug was pretty benign. Calling `(exwm/switch "Dotfiles")` at the
bottom of `window-manager.el` was failing because "Dotfiles" is the name of a
non-existent workspace; it should've been `(exwm/switch "Briefcase")`.
There may have been more problems. I changed a few other things along the way,
including exposing the env vars BRIEFCASE to `wpcarros-emacs` inside of
`emacs/default.nix`.
The important part is that this was a valuable learning opportunity, and I'm
glad that I'm walking away from the two days of "lost productivity" feeling
actually productive.
I'm using a Makefile until I can remember the command:
```shell
> nix-env -f . -i
```
This will install (i.e. `-i`) any derivations instantiated from the Nix
expression resolvable by `-f`. Ideally the incantation will look something like
this:
```shell
> nix-env -f '<universe>' -iA emacs
```
Informing `nix-env` to install all of the derivations created by the expression
at attribute `emacs` in my `<universe>` repository. For now two things are
preventing this:
1. `emacs` isn't an attribute in my top-level expression defined in the
`default.nix`.
2. If I do add `emacs` as an attribute and call the above command, my usage of
`readTree` results in `pkgs` missing `.lib` and a few other stdlib commands
that are available in `(import <nixpkgs> {})`.
A fix for both of these should be forthcoming.
My younger self didn't know that creating repos to house your
configuration was a known pattern! Hence the unweildy name, pc_settings.
This change was a long time coming.
