One of the stranger bugs I have hit recently came from a nice reminder that terminal programs are only simple right up until they are not.
lsv has a preview pane. For text files it is straightforward enough: run a command like bat, capture the output, render the ANSI colour, and fit it into the pane. For images I had been using viu, which works well in a lot of setups.
I have shipped plenty of software inside teams and companies, but publishing a small tool to crates.io has a different feel to it.
lsv is a three-pane terminal file browser I built in Rust with Lua configuration. By the time I started thinking seriously about crates.io, the core idea already worked. I could move around, preview files, run commands, wire up custom actions, and generally use it for real. I had convinced myself the software existed.
The first version of the Sudoku project solved puzzles. That was the easy part.
The harder part was making it pleasant to use.
The repo history for this one is fairly honest. On January 30th I had:
working version in 1 prompt, pretty version in 2 more prompts
That got me over the line into “there is a thing on the screen and it sort of works”. It did not get me to a tool I would keep open and use.
I have a Rust roguelike that ran on desktop. I wanted it to run in the browser as well.
That sounds straightforward until you actually try it.
The game itself was not really the hard part. It already existed. The work was in getting the build chain, the dependencies, and the browser shell to agree on what “working” meant.
You can see the code and the working game, and the original tutorial which is really good:
I have been following the Rust Roguelike Tutorial to build a little Rogue-like with an ECS core. I only got partway through, but it was a fun, focused project and I now have a playable build running in the browser.
Try it here: Rogue.
It is a classic tile-based dungeon crawl with keyboard controls (arrow keys, vi keys, and numpad). The Rust core uses specs for ECS and bracket-lib for the terminal style rendering model. I bridged it to the browser with wasm-bindgen, so it runs as a WebGL canvas.
I wanted a Sudoku editor that feels like a quiet desk: place numbers, track candidates, get nudges, and keep the board readable. So I built one with GPT-5.2 helping me iterate the UI and logic.
You can try it here: Sudoku Editor.
The solver starts with the basics (naked and hidden singles), then escalates through sets, pointing/claiming, fish, and wing tactics. I wanted the hints to be helpful rather than magical, so each step reports the evidence in plain language.
One of the nice things about Sudoku solvers is that they scale badly in an interesting way.
The first steps are easy. Naked singles and hidden singles are not much trouble. You can get a working stepper quite quickly and it feels good because the board starts moving.
But then you need to add the trickier tactics.
The code and the playable version are here:
The main thing that kept this manageable was forcing every tactic through the same output shape.
I finally snapped after one too many trips through modern file browsers on macOS and Windows. Click. Wait. Tiny target. Modal dialog. Repeat. I spend most of my day in a terminal anyway, so I built something that fits how I actually work.
Say hello to lsv.
lf, but with a setup that matches how I like to glue tools togetherYou can bind keys to run shell command. e for example might launch the selected file in your $EDITOR or i use t to launch a new tmux pane for the current directory, or gs which is bound to lsv.os_run("git status -C {current_dir}") to see the results in a results window.
Quick version: I rewired my Asteroids clone from a pile of classes to an Entity‑Component‑System (ECS). Codex (the CLI agent) did the heavy lifting while I poked, prodded, and occasionally muttered at my screen. The end result is cleaner, easier to extend, and less brittle when I add toys like missiles and sparkly shields.
Why bother with ECS?
Where I started (a.k.a. the creaky bits)
The basic idea was simple enough. I wanted a small message queue service with HTTP and JSON, backed only by SQLite. One binary, one database file, no extra infrastructure, something that theoretically would be useful for small jobs and side projects without Redis, RabbitMQ, or a whole second system to babysit.
The repo is here if you want to look at it:
The implementation settled on a fairly tight stack: