It turns out I'm going to need multiple different OAuth clients for a
variety of reasons. This defaults to the client for tazj.in accounts,
but I use a different one in my work overlay.
Instead of splitting below and moving the target buffer into the new
split, split and move the buffer into the active window.
The other way around does (for some reason I don't fully understand)
not work because `split-window-below` may return invalid windows.
Configures edwina using `s-w` as the key prefix (in line with my other
EXWM-related commands).
An additional function is added that switches to a buffer (borrowing
the implementation from `ivy-switch-buffer`) but splitting it into a
new window instead.
Don't re-send the welcome message when loading the game if it's already
been sent. This is done by just tracking whether or not we've sent it as
a boolean in the game state, which may be a bit of a hack but should be fine
Recalculate the character's lines of sight every time we step the game,
rather than just every time the character *moves*. I had originally
thought this was a non-contiguous lines-of-sight bug - which there's a
test disproving - but it actually turned out to be that actions like
eating or attacking would step the game forward (thus moving gormlaks)
without re-calculating the positions visible to the character.
Make the setter for the atPosition lens preserve entityIDs for
already-existing entities at the position, so that when we plop
something in the same tile as the character the character's entity ID
doesn't disappear.
Add a drop command, bound to 'd', which prompts the character for an
item in their inventory, removes it from the inventory, and places it on
the ground. Along the way I had to fix a bug in the
`EntityMap.atPosition` lens, which was always appending to the existing
entities at the position on set, without removing the entities that were
already there - the rabbit hole of quickchecking the lens laws here also
lead to replacing the target of this lens with a newtype called
`VectorBag`, which ignores order (since the entitymap makes no
guarantees about order of entities at a given position).
When attacking, use either:
- the message defined on the entity raw of the wielded item, if any
- the generic attack message, if an item without an attack message is wielded
- the fists attack message, if no item is wielded
Use whatever items the character has wielded, if any, to calculate the
damage they deal when attacking. Currently this shortcuts handedness to
just use the *first* item they have equipped, which is fine since it's
currently only possible to equip something in the right hand.
Add a Wield command, which prompts for a wieldable item, if any, to take
out of the character's inventory and put in their right hand.
Eventually we should support other hands, but for now hardcoding the
right hand should be fine.
Split the character's inventory up into wielded items (in one or both
hands) and the backpack, and display wielded items when drawing the
inventory panel. Currently there's no way to actually *wield* items
though, so this is all unused/untested.
Also, add the ability for items to be "wieldable", which gives specific
descriptions for when attacking with them and also modified damage.
Implements fully static (i.e. no JavaScript!) highlighting of code
blocks when rendering Markdown.
This works by walking through the Comrak AST and replacing any code
blocks with pre-rendered HTML blocks.
Syntaxes are chosen based on the "block info", which is the string
users put after the block's opening fence. This can either be
a (case-insensitive) name of a syntax, or alternatively a file
extension associated with the desired syntax.
The theme is set to one that imitates GitHub.
This will render about pages using the Comrak renderer defined in
Cheddar.
Note that due to the way its implemented this will have one
interesting behaviour: Markdown files in the tree will *also* be
rendered as HTML.
I will need to see how that works out before deciding whether or not
to disable it.
Renders any ".md" file by pushing it through the Comrak rendering
pipeline.
This does not yet implement syntax highlighting of fenced blocks, but
we're getting there.
Generalises the two bits of the program that will be required either
way (extension parsing and syntax loading).
A dependency on Comrak is introduced as I think GitHub-flavoured
Markdown (with all its fancy extensions) is desirable!
This uses Nix to inject the path to the syntax highlighting assets
that ship with the bat source code into the cheddar build at compile
time, where the Rust compiler then inserts it into the binary via
macros.
bat has a lot of custom syntax highlighting definitions that they
collected from all over the place (including for languages like Nix!)
and this makes them accessible to cheddar.
Also if you're reading this, can you just take a moment to appreciate
how incredible it is that Nix just lets us do something like this?!
The first step with this tool will be to use it as a source-filter for
cgit. The second step is to use it as the Markdown renderer by
depending on one of the Markdown libraries, with integration for
rendering code snippets directly.
