After a five year hiatus, I decided to attempt to solve the famous N queens
problem again. This time, instead of modeling the chess board using a
`[[Bool]]`, I'm using `[Integer]` where the `Integer` indicates which column has
a queen. This is a bit lighter in RAM.
I could have and should have broken this change into smaller pieces, but when I
came up for air, I had changed too much, and most of the changes are
intermingled. Oh well... this is an exciting change!
Include habits for:
- Morning
- Evening
- Payday (the 25th)
- First of the Month
- First of the Year
Since the Morning and Evening routines might be a bit noisy, I'm excluding them
from the output using a flag, `include{Morning,Evening}`, which I support in the
UI to toggle their visibility.
I made *much* more progress on this app that I expected to today, and I *think*
-- short of supporting a database and a server -- I'm close to
being *completely* finished.
Wahoo!
Instead of accepting `List (String, Int)`, accept `List Strategy` where
`Strategy` defines whether or not the string of selectors should be applied to
the element.
I'm also renaming it `class` so I can just use `Utils.class`; `tailwind` has
little to do with the function itself.
Create UI.elm to house components like `button`, which is a simple HTML button
with `focus:outline-none` applied as a `class`, which is an accessibility
feature that I don't need for this touch-screen application.
I like this pattern more than my more opinionated patterns for UI modules in Elm
where I'd define all of the arguments as a record type (i.e. kwargs).
Use the Google Fonts API to fetch a handwritten font, which gives the app a
modicum of personality. There are more "best practices" ways to do this, such
as:
- Download the font once, and include it in the bundle
- Extend the Tailwind configure to recognize the font
- Ditch the inline <style> block
But I don't need the performance benefits that the first bullet provides. And
the second two bullets are more relevant for a larger application with more than
one font. So I think in this case, the easiest solution is best.
Also:
- Use `container` and `mx-auto` to constrain content for wide screens
Created a small MVP for digitizing my weekly habits. Much more to come.
Lots of things happening:
- Copied the boilerplate to get started
- Added a brief project-level README
- Outlined my ambitions in design.md
See README and design.md for more context on this project.
When `keybindings` requires `window-manager`, the `evil-want-integration`
warning emerges. If I remove the `evil` dependency from `window-manager`, it
resolves the issue.
I was tired of using `arandr` to manually configure my monitor positions, so I
encoded the settings in Elisp in the `display.el` module.
TL;DR:
- Drop support for `position` kwarg in `display-register` macro
- Support `coords` kwarg in `display-register`.
- `defconst` the `xrandr` arguments and command in `display-register`.
- Define `display-arrangement` macro that consumes the `xrandr` arguments that
`display-register` defines to create an interactive function,
`display-arrange-<NAME>`, which -- when invoked -- runs one xrandr command to
configure a display "arrangement".
Why didn't I configure this earlier? For years, my workflow involved checking a
buffer's major mode and then extending that major-mode's hook. Confusingly (to
me), the `major-mode` for `COMMIT_EDITMSG` is `text-mode`, and I didn't want to
disable `company-mode` for *all* `text-mode` buffers, which is what the
following would have done:
```elisp
(add-hook 'text-mode-hook (lambda () (company-mode -1))
```
Thankfully I recently invested some time into learning more about Emacs's
offline help system, `Info-mode`, so -- putting that knowledge to work -- I ran
`info-apropos` and searched "magit commit". After ~5 minutes of reading I knew
the recommended way of configuring this was to modify `git-commit-setup-hook`.
How validating!
I haven't updated this list since I was living in Dargow, Germany over the
summer. Now that I've settled down, and I'm situated in the London Bridge area,
I'm updating the list.
I want to couple my EXWM workspaces with monitors. E.g. - I'd like my "Chatter"
workspace to prefer my `4k-vertical`. This change supports that.
I also did a small amount of formatting, which I don't think belongs in a
separate commit.
This is a helpful reminder to ensure that the exchange rate is always
fresh. Ideally I could use Google Sheets formulae to take a snapshot of the
GBP:USD exchange rate *at a point in time*, but I haven't set that up yet. Maybe
it'd look something like:
```pseudocode
=GOOGLEFINANCE("GBP:USD", "September 1, 2020")
```
I'll have to look into this.
My newly minted macro for defining monitors introduced two bugs:
1. Laptop defined its position in terms of 4k-horizontal and 4k-horizontal
defined its position in terms of laptop, I introduced a circular dependency.
2. The identifier, `laptop-monitor`, which `window-manager.el` depends on, is
now defined as `laptop`.
A friendly reminder to myself to always test new Emacs builds to make sure that
everything can initialize properly. This is something that my CI should be
automating, but ever since I moved flats, I lost my CI and need to restore it.
This is another reminder to drop into a TTY when Emacs fails to initialize, run
`nix-env --rollback`, then attempt to restart X. But this time, debugging this
entirely from a TTY wasn't so disappointing.
I recently acquired a new monitor, which I'm orienting vertically for logs,
chats, etc. As such I needed to add more functions, KBDs to wrangle the
setup. To DRY up my code, I define a macro, `display-register`, as a DSL for
supporting new monitors. This:
- defines two functions for enabling and disabling the displays
- defines a constant, `display-<name>`
It's basically just a wrapper around `xrandr`, and that's good enough for now.
