This weekend, I built a language server for CEL called cells. It currently supports semantic highlighting, diagnostics, documentation on hover, signature help, references, document highlighting (for variable references), completion, and formatting. CEL is a pretty simple language, so a language server for it doesn’t really need to support things like go to definition or some of the other niceties that language servers typically support. It only works on a single .cel file at a time, which is a filetype currently supported only in neovim nightly but will be supported in neovim 0.12.

Building this out, I brought over some of the ideas that I had integrated when I was building out some of the Buf LSP server at $WORK, like that tests should have separate testdata files so that they could be independently verified by opening up an LSP-powered editor and taking a look at the files themselves. On top of this, making the tests mostly table-based made it really simple for additional test cases to be added.

Of course, building this in a weekend took working with AI (using pi and amp). One thing I had in mind was trying out the other LSP “frameworks” in the go ecosystem; unfortunately, most seem to be pretty unmaintained these days. go.lsp.dev progress has largely stalled, and tliron/glsp was the only other major contender, which seemed to be in a similar state.

At the end of the day, the agent suggested that we ought to just borrow what charmbracelet had down with powernap, and vendor in the gopls protocol code while maintaining the license, and then “write” our own JSONRPC server, based on the sourcegraph implementation, but without the legacy cruft. I may end up upstreaming some of this approach to buf lsp.

I’m not sure how many other LSP features cells needs to be considered “complete”, although I’ll continue to track CEL language features (as it’s still in a pre-1.0 state as a language), and I’d like to add most of the LSP features as functionality in the CLI, similar to gopls’ CLI interface.

cells turned out to be a pretty perfect weekend project for working with agents: LSP is fairly well-specified, with existing patterns, a tight feedback loop, and a great reference library in cel-go.

Fun times to be building things. 👷‍♂️

Growing up playing World of Warcraft (WoW)¹, I became familiar with the concept of “Fog of War” — that is, areas of the world that your character hadn’t visited. Once you moved close enough to a certain area on the map, the fog would “lift”, and that area on your map would be filled in moving forward. Also, you’d gain experience points for clearing Fog of War — at lower levels of the game, you could level-up fairly quickly just by exploring new areas.

I’ll give my brother credit — he was the first to see this as an opportunity for exploration. He piloted his Troll Rogue, Zuljitan, on a journey across the continent of Kalimdor after reaching level 10, the level at which Rogues in those days learned their “Sprint” ability. (We figured we’d need this to escape the various mobs that would attack your character from long distance, being tens of levels above our characters. Rogues also could “stealth”, i.e. become invisible at the cost of movement speed, but mobs at such a large level differential could see through stealth.)

Setting off south from the Crossroads in the Barrens, Zuljitan traipsed through the Thousand Needles down to Tanaris to visit Gadgetzan, I believe he then made his way through Un’Goro Crater to Silithus, then over the mountains to Feralas before ultimately dying for the umpteenth time in Desolace and hearthstone-ing back $HOME.

Although I originally played Horde (a Tauren Warrior), I eventually became drawn to the Gnomes of Ironforge, and ended up on my own journey as the Gnome Rogue, Phread. I liked that Gnomes had an advantage in the Engineering profession, and thought it was neat that I could build goggles for my character at a low level, when most headgear in the game was at that time for levels 40+ (of the original level-cap at 60).

The plan was hatched: this time, on Azeroth, I’d need to make my way across the sea to Gadgetzan to get the schematics I was looking for. Phread’s journey was a little easier: taking the Deeprun Tram from Ironforge to Stormwind, he headed south through Elwynn Forest, Westfall and Duskwood down to the far south of Stranglethorn Vale’s Booty Bay, where he could catch the ship to Steamwheedle Port and continue onwards to Gadgetzan. I bought my schematic (I think?), and hearthstone’d $HOME.

I’m now about 20 years removed from my WoW-playing days (wow!), but I’ve managed to find a new way to clear Fog of War: CityStrides. CityStrides is an app that lets you keep track of the streets that you’ve run (or walked, or biked) in a city. Once you’ve run an entire street (by completing all the “nodes” along it), it’s added to your completed list. Each city has a leaderboard of users ranked based on the percentage of streets they’ve completed.

I managed to make my way through 25% of Boston’s ~4,400 streets before we moved to Ipswich in late January. Ipswich has only 356 streets at the time of writing. (The smallest “city” I’ve run, Sunfield, MI, has 18 streets — running 5 of them during a 5k over 10 years ago has resulted in me being the #1 (of 1) runner there on CityStrides.) Before the move, I had nearly run 20% of Ipswich, mostly by running the various roads out on Great Neck and Little Neck. I made it my goal during paternity leave to finish as many streets in Ipswich as possible (thanks to a loving, supportive wife and a relatively reasonably well-behaved baby), hoping to possibly make it to 100% before my leave ended.

I’ve been meaning to write this for a couple months since paternity leave ended, but hadn’t quite had the gumption to get this finished. I haven’t finished the 100% I was hoping to get to: instead, I’ve been stuck at 80% for most of the summer. The remaining streets are all 5+ miles away from my typical starting point of our home, and are largely in areas that I’d classify as unfriendly to running. I’m now slowly restarting my quest for 100% (VanBurens are box checkers, after all), with an eye towards finishing by the end of the year. I remain, for now, 2nd out of 506 on the Ipswich CityStrides leaderboard.

Still, it’s not about reaching 100%: it’s about understanding the area in which you’re living at a deeper level, and looking closely at things (although, maybe not when cars are screaming past you as you try to traipse down some of the unfriendly roads). Clearing the Fog of War, if you will.

🌄

Since moving out to suburban Ipswich from Boston, I’ve been on a “seasons” kick — you know, those things that feel wonderful the first couple weeks they’re here and then eventually drag on until the next one comes along? (Currently waiting patiently for Autumn to get started in New England!)

While I’m more thoroughly immersed in the seasons now than when I was in the city, I still spend a considerable chunk of time computing. Computing isn’t seasonal, unless you make it so.

Since I came across Ross Zurowski’s smallseasons.guide (which details the Japanese concept of sekki, or two-week-ish “seasons” — Ross goes into detail on this and other ponderings in “On Small Seasons and Long Calendars”), I’ve had the iCal humming along in the background, eager for a chance to put it to use.

We’ve had our first hint of Autumn weather this last week, and I saw my opportunity. Fall supposedly starts on September 21st around the equinox (and then lasts until December 21st 🙄), but everyone knows this is a hoax. Autumn actually starts much earlier: August 8th, based on the sekki. I configured neovim to change between echanovski’s mini{spring,summer,autumn,winter} colorschemes based on the change of the small seasons, and similarly updated my site’s <h1>s and favicon to follow suit.

Just a little thing to keep me grounded in the seasons, despite the indoor setting, along with our morning stroller walks!

🍂

P.S.: Another way I’ve found to mind the seasons is to update my Living Worlds app on the first day of each month, as a reminder of the passing time.

I was lucky enough to be included in the inaugural Internet Phonebook, in the “Atmosphere” section on p. 22 — I’m number #58 if you’d like to Dial-my-site.

I ordered a copy to peruse for myself, and lo and behold, I had forgotten that I had submitted on a whim. Probably the first and last time a link to this little site of mine will appear in print. Still, glad to be included in, and support, this grand directory of the poetic web.

My Overcast settings screen shows the following:

Smart Speed has saved you an extra 949 hours beyond speed adjustments alone.

That’s a lot of time. I’ve been using Overcast to listen to podcasts since it launched, with years now of what-I’d-call “heavy” podcast listening. I’ve spent most of that time listening on 1.5 or 2x speed, with smart speed always turned on (after all, who can resist number-go-up).

I recently read Keenan’s “Hot Take: It’s okay if we don’t consume all of the world’s information before we die”, and then subsequently also listened to the audioblog version. While listening, I turned off Smart Speed, and it really struck me the difference that I’d been missing all this time. It’s not as though I didn’t intuitively know that the audio was sped up, but there’s something different about listening to people talking to each other without pauses.

For one, you might assume that the speakers are more intelligent: they never need to consider their responses, as they’re always immediately responding. In a similar vein, there’s no context clues as to what one person said that made others on an episode take time to consider - which might be important than something that can be responded to immediately. And of course, as Keenan mentions in his post, for the producers that do edit their audio, using Smart Speed removes the potential to appreciate the pauses as they occur, whether they’re within conversation or somewhere else.

Back to Keenan’s audioblog, you can clearly hear this listening to the end of the podcast as he slows down for emphasis towards the end.

All of this is much better articulated by Simon Sarris in his thoughts on audiobooks, where he notes:

Listening is a skill … Generally the pacing of nearly all media has quickened. Possibly the delivery of “more, faster” is the result of a too-great respect for novelty as an artistic flourish.

Clearly, none of this is groundbreaking - but reconsidering using Smart Speed has been a nice change of pace.

🐢

Inspired by https://defaults.rknight.me, here are my current defaults:

• Mail Client: Mail.app
• Mail Server: Migadu
• Notes: Drafts
• To-Do: Things
• iPhone Photo Shooting: Camera.app
• Photo Management: Photos.app
• Calendar: Calendar.app
• Cloud File Storage: iCloud Drive
• RSS: NetNewsWire (client) + Feedbin (server)
• Contacts: Cardhop
• Browser: Safari
• Chat: Messages
• Bookmarks: Pinboard
• Read It Later: Instapaper; transitioning back from Reeder’s read-it-later
• Word Processing: n/a
• Spreadsheets: n/a
• Presentations: n/a
• Shopping Lists: Grocery
• Meal Planning: Drafts / Mela
• Budgeting and Personal Finance: n/a
• News: Hacker News / lobste.rs / text.npr.org
• Music: Spotify / Doppler
• Podcasts: Overcast
• Password Management: 1Password

Also see my /uses page for other hardware / software!

Inspired by Louie Mantia’s CSS for This Blog, I figured I’d publish the page I use locally for testing out how my CSS looks.

It’s over at /style-guide (source) and it’s basically a dump of the markdown tab on bryanbraun.com/poor-mans-styleguide. A great, simple way to see the various styles for most everything on the site.

A quick retrospective on my November Goals post:

Run 80 miles

I fell a little short here, running just 58 miles for the month. But it was busier than I gave myself credit for: a trip to see friends and being on call for two straight weeks made things a bit tricky. I should still be in good shape to get to 1000 miles for the year, which would likely be the most I’ve clocked in a year, ever.

No drinking during the week (except Thanksgiving!)

Mostly good! I might have had ~two days where I went out with friends during the week for a beer (or several), but overall was contained to weekends and Thanksgiving. Going to keep things going into December!

I’ve been a little hesitant to write here, for whatever reason. Haven’t had the gumption to write, I suppose. So I’d like to start up a bit of a habit — call it a “reverse New Years resolution”: I’d like to write something here (either a blog or TIL) each day until the end of 2022.

s/each day/each week

A bit too much, I think, to post each day. But I’m glad to have started up the habit of thinking about what to write again, even if it’s inconsequential.

Watched “The Blair Witch Project” last night as a bit of a pre-Halloween treat. Two thoughts:

1. Some movies are just better in theaters.
2. (Maybe related!): The bar for “scary” has gotten higher in the last 20 years.

Either way, worth the watch. Just don’t read the Wikipedia page first, and pay attention — the found-film effect can be jarring.

I’ve spent a decent amount of time tweaking my … “system” for reading articles and blogs on the ’net that I figured I’d jot down what I’ve tried, and what’s currently working for me.

I currently use two separate but related tools for reading the web: a feed reader, and a “read later” app. My first feed reader was Google Reader until its untimely demise, followed by a long while of using newsbeuter to intermittently follow feeds. And for “read later”, I started with Instapaper, close to the time it was initially released.

Eventually, I stumbled on Feedbin, which has hosted my feeds ever since. Feedbin is great for many reasons, including: muting feeds; the autogenerated email address for newsletters; the friendliness and speed of the interface. But I’ve never used it as a primary client for actually reading my feeds — I’ve always preferred a native client over a web client where I can get one.

And thus, to start with: Reeder.app. Reeder was my go-to feed reader since at least Reeder 3, and it paired nicely with Instapaper.

I stuck with this setup for a long time. Eventually, though, I had ended up with too many saved articles in Instapaper. I tried splitting things out into folders to make “Home” more manageable; eventually, I settled on a “Long” folder that was for anything that Instapaper deemed to be over a “10 minute read”, and everything else was left in “Home”.

I eventually declared bankruptcy on Instapaper, for a few reasons, not least of which involved Instapaper being primarily web-based (at the end, I could feel the latency of talking to the server to interact with the app at all, despite Instapaper’s “native” apps).

Next, I switched over to Reeder’s built-in “read later” feature, which let me send articles over to a more permanent archive, where they wouldn’t be cleared out after having been opened. This was great — using the same app for both “triaging” the feed and also for reading longer articles. It helped, too, that Reeder is a beautiful and thoughtfully designed app.

But the reading experience wasn’t without bugs: for longer articles, if I switched away from the app while reading, it would very regularly lose my place in the article. And with the app being developed by a single person (as far as I know) with seemingly most of their focus on their new (similarly fantastic) recipe app Mela, I wasn’t sure things would get fixed in the near future.

After trying out a few alternative clients, I settled on NetNewsWire (NNW). NNW feels native. And simple. It’s free and open source (still (reasonably) actively developed), and has apps for both macOS and iOS. Truly Mac-assed.

NNW doesn’t have a “read later” feature, but/and I’ve come to like that: I now only use Reeder as a “read later” app, and send articles to it from NNW. And funnily enough, the extra bit of friction of not having a keyboard shortcut to send to Reeder’s “read later” (instead, needing to use NNW’s share menu) has kept me from adding too many articles, and makes me more considerate of what I add to my “read later” queue.

Anyway — I wouldn’t call this setup perfect, but it’s been working out well for me over the past year or so since I’ve adopted it. Feedbin (feed sync and management) → NNW (client) → Reeder (read later).

One important caveat in this whole setup: I only use the macOS version of NNW, even though there’s an iOS version, because I like to keep the number of “inboxes” and consumption opportunities on my phone to a minimum. I’ll talk about that more in a later post!

Setting some November goals a little early:

1. Run 80 miles

   I set a goal of 500 miles this year — I’m already at 864 miles for the year, most of which I ran in the early summer. I’d really like to pass 1000 for the first time in a long while, and if I’m not at 950 by December, I can tell I’m not going to make it. 20 miles a week should be reasonable, given that I was getting up to 30-40 during the summer.

2. No drinking during the week (except Thanksgiving!)

   I’d like to drink a bit less — with the ramp up on running, and an on-call shift or two coming up, I’ll be avoiding drinking during the week, up until the holiday later on next month.

I’ve been a little hesitant to write here, for whatever reason. Haven’t had the gumption to write, I suppose. So I’d like to start up a bit of a habit — call it a “reverse New Years resolution”: I’d like to write something here (either a blog or TIL) each day until the end of 2022.

Grease the Groove, they say. Don’t worry about who’s reading (certainly not many!), and write like I’m writing to one person.

We’ll see how it goes.

Recently I polished up and published my seven-guis project. It’s an implementation of the 7GUIs “GUI Programming Benchmark”, written in ClojureScript and Reagent.

It’s not quite complete — there are 7 tasks, and I finished all except for the last one (the spreadsheet — the most vaguely specified and open-ended, and the most difficult). I’ll finish it down the road, but for now I’ve hosted it at seven-guis.vanburen.xyz, and the source code is public, at github.com/stefanvanburen/seven-guis.

I’ve added a new uses page, detailing my personal computing setup. I’m hoping to make it more prose-like in the future, but for now it lists my current most commonly used hardware and software.

A quick domain update:

• svbn.me -> stefan.vanburen.xyz

and to match, an email address update:

• me@svbn.me -> stefan@vanburen.xyz

Will hold on to the old domain for awhile, so it should still work, but most things are being redirected.

At $work, I’ve been writing a web application that is server-side rendered via Go’s html/template package.

I’ve been writing a toy application in Clojure with a similar approach: server rendered HTML with Tailwind for styling and AlpineJS for a hint of interactivity.

With the introduction of Go’s new embed package in 1.16, I was tempted to port the application to Go. I was imagining being able to embed the templates and assets in a static binary.

And I could still do that! But I hesitated as soon as I reached the portion of rewriting my templates in Go, and for good reason: Go’s template syntax isn’t great, and Clojure has Hiccup.

Hiccup #

Hiccup is a library for writing HTML in Clojure. Writing HTML in Hiccup is a dream:

• Unlike HTML, Hiccup automatically closes tags.
• Hiccup doesn’t require that you remember the proper way to close an HTML element.
• Hiccup has shortcuts for adding an id or class attributes.

And, more than anything, Hiccup is written within your regular Clojure functions, which makes it incredibly easy to interweave logic with your templates.

A <form> in Hiccup might look like this:

[:form {:action "/add-address"
        :method "POST"}
  [:label {:for "label-input"} "Label"]
  [:input {:type "text"
           :id "label-input"
           :name "label"
           ;; for now, label is required
           :required true}]

  [:label {:for "street-input"} "Street"]
  [:input {:type "text"
           :id "street-input"
           :name "street"}]

  [:label {:for "city-input"} "City"]
  [:input {:type "text"
           :id "city-input"
           :name "city"}]

  [:label {:for "state-input"} "State"]
  [:input {:type "text"
           :id "state-input"
           :name "state"}]]
;; …

The beauty begins when you start to weave in the logic:

(def disabled-classes "text-gray-500 …")

(defn button
  [id classes disabled?]
  [:button {:id id
            :class (if disabled?
                     (merge classes disabled-classes)
                     classes)
            :disabled disabled?}])

In this way, Hiccup is similar to the JSX syntax while writing React — and this approach has been taken to the ClojureScript side via the Reagent library. (A more thorough example of Reagent-style Hiccup code can be found in my seven-guis project).

And, when you pair Hiccup with Parinfer + Conjure, the DX is too good to pass up. While I love writing Go, the conciseness, simplicity and the REPL of Clojure have drawn me in. It’s magical.

🪄

I was reminded of the font-variant-numeric CSS property by Jim Nielsen, here, and ended up using it in a similar way for the dates on my list of blog posts.

For context, without tabular-nums enabled, numbers on this site look like this:

0123456789

And with it enabled, they look like this:

0123456789

At least on Apple platforms, where the system sans-serif font is San Francisco, the “0” and “1” characters have a little additional spacing, making them equal size to the rest of the digits.

Glad to get this changed — the previous look was somewhat off-putting, now that I look at it in comparison. There are so many neat CSS properties nowadays for all sorts of typographical situations.

Recently I was building a new website in go at $work and needed to do some URL parsing to grab some expected parameters in the URL. The URL was expected to look something like the following: /path/:id1/:id2, where I was trying to grab id1 and id2 out of the URL.

In the past, I’ve done something along the lines of:

splitPath := strings.Split(r.URL.Path, "/")

// error handling, etc.

// splitPath is ["", "path", ":id1", ":id2"],
// because of the way `strings.Split` works
id1 := splitPath[2]
id2 := splitPath[3]

However, I had come across the following code, from the source code of builds.sr.ht:

var (
	jobId int
	op    string
)
_, err := fmt.Sscanf(r.URL.Path, "/job/%d/%s", &jobId, &op)

fmt.Sscanf? Haven’t seen that in use often! But it seemed like a great fit for the exact problem I was solving.

So, I tried it:

var id1, id2 string
matchCount, err := fmt.Sscanf(r.URL.Path, "/path/%s/%s", &id1, &id2)
if err != nil {
	fmt.Printf("err: %s, match count: %d\n", err, matchCount)
	fmt.Printf("id1: %s, id2: %s", id1, id2)
} else {
	fmt.Printf("no err, id1: %s, id2: %s", id1, id2)
}

Here’s a slightly modified version on play.golang.org.

So, the first match hit by the scan, because it’s %s, continues through the / character and picks up id2’s value as well, leaving nothing for id2.

So why did it work in the line of code shown above?

Because the %d format specifier only captures numeric characters, so the / character breaks up the scan.

I messed around with this approach for awhile, but ultimately gave up and went back to my approach using strings.Split. But, it’s a nice reminder that format strings in go can be used both for formatting output and for scanning input, even if there are some footguns attached.

🔫

A quick update: I’ve put the repository in maintenance mode, and started work on a neovim colorscheme based on the same colors. The end goal is to have a generalized colorscheme that can be exported for use elsewhere.

I published the vim colorscheme I’ve been using for the last few months publicly on GitHub. It’s called rams.vim, after the German Designer, Dieter Rams.

I had the idea for the colorscheme after watching Gary Hustwit’s Rams. It’s simple: off-black, off-white, a grey and an accent color (a medium-bright red). I also added a green and red that are specifically for showing diffs in vim.

The colorscheme is generated via vim-colortemplate, which aided the creation greatly — I have no previous experience with vim colorscheme creation, and based on the other colorschemes I surveyed, it seemed like one of the few sane ways to get an idea up and running quickly.

I’m quite happy with the colorscheme as is — I’ve been using the light colors for a couple months now. The dark mode could use some work, but I’m not using it regularly, so I’ve been mostly keeping it in sync with the light variant. I’ve also added some plugin-specific highlights for the obvious candidates (ALE, fugitive / gitgutter), but haven’t explored all of the plugins I kept around after my dotfile purge.

If you’re a vim user, give it a try, and let me know what you think!

I was browsing through my GitHub repositories the other day and noticed small, a CLI tool I started working on about two years ago to convert text. I finally polished up the repo and published it for all to see.

It’s really not much, but it gave me a chance to think about the expected behaviors associated with a tool like small. In particular, support for being piped ($ command | small) is a critical bit of playing nice with other UNIX-y tools.

Anyways, it was fun getting it out there.

$ small -h
USAGE
  small [FLAGS] [TEXT...]
  command | small [FLAGS]

FLAGS
  -h         print this help message
  -l         list transform types
  -t=TYPE    specify transform type

$ small "here's some text!"
ʜᴇʀᴇ'ꜱ ꜱᴏᴍᴇ ᴛᴇxᴛ!

🤖

I recently learned of “prutsen”, a Dutch word meaning “to fiddle around”. In a lot of ways, I think it encompasses a lot of how I approach some of my computer diversions.

For example, this website, at the time of writing, has 135 commits on it. With a total of five published posts, and most of my posts being written within a commit or two, much of the work being done on this site is cosmetic. For example, tweaking CSS indentation or ensuring the RSS feed contains the entire content of the post.

Likewise, my dotfiles sit at a healthy 910 commits currently. I recently went through a bit of a dotfile purge that added quite a few of those, but in general, tweaking my dotfiles has been a hobby for the better part of a decade.

Prutsen gives me a name for all this tweaking and fiddling — so cathartic!

💆

Update: After this post I truly could not remember where I had found “prutsen” in the first place. I finally found it: Do Inhabit, by Sue Fan and Danielle Quigley.

From the book:

Good to know where it originally came from!

I’ve recently moved from a largely merge commit based git workflow to a squash and merge based one. Learning to flex my git rebase muscles has been refreshing, and I’m enjoying the cleaner git log that results.

As part of the workflow, I’ve changed my git pull to default to rebasing on pull, rather than merging (the default). The only thing that’s rough about this workflow is whenever I have local changes, git pull will fail, telling me that I have unstaged changes:

$ git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.

To work around this, I’d typically do a compound shell command (I’m using fish — you would typically do this with && in bash):

$ git stash; and git pull; and git stash pop
Saved working directory and index state WIP on main: 79911a7 chore: Remove gemini
Already up to date.
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   content/blog/git-pull-autostash.md
        modified:   content/blog/small.md

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (2ecce561c9bbd9cf222848d4b225a49edb816bb2)

I recently discovered the solution to needing this: git pull --autostash! It automatically stashes your current working directory and re-applies it after the pull.

$ git pull --autostash
Created autostash: a14af18
Current branch master is up to date.
Applied autostash.

This option is so handy for my workflow that I made an alias for it.

🥳

Spring is in the air! Inspired by Deletion Day, I’ve been tidying up some of my physical and digital life. I’ve deleted old accounts, removed applications that I’m not using, and gotten rid of extraneous hardware. But, the cleanup I’m most proud of is my dotfiles cleanse.

the purge #

For awhile, I was a bit of a dotfiles packrat. I worried that the knowledge I had gained — the choices I had made — would be lost to the depths of time if I were to remove them from the text of the files themselves. That meant old color schemes, old key bindings, old tips and tricks, all stayed in their respective places. Perhaps moved around, but not deleted. Over the years, this meant that my vimrc had bloated up to ~1600 lines! I had also accumulated a lot of files for tools I’m no longer using, that were strewn all over my system.

I finally reached a breaking point, removing the cheat tool. There was nothing wrong with it, but I wasn’t using it as often as I thought. I used this as momentum to move on to my other configuration files, mostly my vimrc. Previously, I had been fairly lax on my git hygiene for the repo, using commit messages like “Various updates” or simply a "✨". I knew that removing all that accumulated knowledge meant that I needed to have better practices, so I started using a tool: prefix on my commit subjects, and trying to be better about abiding to atomic commits.

(neo)vim #

Now, my vimrc is a lean ~350 lines! Update (August 2022): I’m now fully in on the Lua (actually, Fennel) neovim configuration, so the previous link is invalid. (Maybe not lean for a vanilla vim purist, but it’s reasonable for me!) You’ll also notice that I’ve converted over to neovim fully. I had a number of settings, plugins, and mappings that were working around some of vim’s weirdness, and I was using neovim 98% of the time. I removed all the settings that were the default in neovim and did a lot of :help diving to understand the settings that remained. I also dropped plugins that I used sparingly, some of the filetype specific autocommands, and the sectioning comments used for folding. I’ve added a few plugins back that I wasn’t quite able to shake (notably, I tried to learn vim’s builtin autocomplete commands, but found deoplete to be something I couldn’t avoid using).

XDG Base Dir #

Switching over to neovim meant that I could remove the hacks around neovim finding vim’s configuration directory, and move everything to ~/.config. I could also leverage neovim’s data dir for storing my plugins. Given the neovim changes, I started to look elsewhere where I could move my dotfiles in ~/.config, and managed to get everything except .tmux.conf moved over. This includes my global git configuration, which until now I didn’t realize could be anywhere but ~/.gitconfig and ~/.gitignore!

other configuration #

Alongside the effort to move everything to within ~/.config, I ended up removing language specific configuration (mypy, isort, and flake8 config for Python, profiles.clj for Clojure), tooling configuration (curlrc, editorconfig, vale.ini), old package listings (Brewfile), and unused shell configuration (zprofile, zshenv, and zshrc). Overall, I’ve reduced my dotfiles down to things that I use now.

And it feels great.

🛁

Rating: 4/5 ⭐️

Warning: Spoilers below

Mr. Penumbra’s 24-hour bookstore is an amusing and intriguing tale concerning a new clerk at a strange bookstore who uncovers the mysteries of his new place of work. Clay (the clerk and main protagonist) discovers a secret society that his employer is a part of, and seeks to bring the mystery to light.

I came into contact with the title via Robin Sloan’s blog for 2019, Year of the Meteor, which I’ve adored. The assortment of links and life commentary has been wonderful all year, and I’m looking forward to Sloan’s next project.

Overall, the book flowed well and moved quickly; I’m not a very fast reader and made it through in around 5 and a half hours total, largely over the course of two days. The writing included a lot of references for a more technical crowd — or, at least, a crowd familiar with the Silicon Valley startup scene. There were a handful of mentions of Google specific technologies, as well as allusions to computing history.

However, I felt the novel was lacking in the department of having a serious antagonist, and a bit too much feeling of Deus ex machina at the end. The novel’s antagonist, Corvina, had essentially no chance of stopping the protagonists from achieving their goal. Meanwhile, when everything seemed lost after a failed attempt at code-breaking with the entirety of Google’s compute power, and the rest of the novel being largely about the protagonist’s ability to bring together his eclectic set of friends’ talents to bear on the mystery at hand, the story is resolved by Clay on his own.

A feel-good ending was somewhat ruined by the quickness of the last third of the book. But still, I was entertained the entire way, and recommend giving it a read.

I recently switched from zsh to fish as my shell of choice. I liked the idea of starting from scratch, with the sane defaults that fish provides, as my zsh configuration files were getting a bit out of control.

For the most part, the transition was fairly painless and straightforward. However, I still miss a few of the zsh niceties that I had been used to over the years — one being extract function provided in oh-my-zsh. Even after moving away from oh-my-zsh as my plugin manager in zsh, I had used my new manager to grab just that plugin for my usage.

After a cursory google, it seemed like a fish port of the plugin didn’t exist, so I decided to try to port over the plugin myself. You can find the whole function in my config.fish in my dotfiles.

First, we’ll define a function named extract and give it a description. I’ve also noted in a comment where this function was ported from.

function extract -d "extract files from archives"
    # largely adapted from
    # https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/extract

The function first checks if we have arguments — if we have none, there’s nothing to do, so we’ll echo a usage string to stderr and exit.

    # no arguments, write usage
    if test (count $argv) -eq 0
        echo "Usage: extract [-option] [file ...] " >&2
        echo " Options:" >&2
        echo " -r, --remove    Remove archive after unpacking." >&2
        exit 1
    end

Next, we check to see if the -r / --remove option has been supplied as the first argument. If it is, we’ll remove the archive files after they’ve been successfully unarchived. We also remove this argument so that our main loop can iterate correctly over the filenames.

    set remove_file 0
    if test $argv[1] = "-r"; or test $argv[1] = "--remove"
        set remove_file 1
        set --erase argv[1]
    end

Now comes the main loop, which iterates over the filenames supplied.

    for i in $argv[1..-1]

First, we ensure that the filename arguments are valid files:

        if test ! -f $i
            echo "extract: '$i' is not a valid file" >&2
            continue
        end

We default our success value to 0 — if the file’s extension isn’t something we can deal with, we’ll set this to 1 so that we can avoid removing the file even if the remove option is set. Then, we grab the extension via some fish regex matching, using the string match function.

        set success 0
        set extension (string match -r ".*(\.[^\.]*)\$" $i)[2]

Now, we’ve reached the main switch statement, which is largely a translation of the zsh version’s unarchiving calls to fish.

        switch $extension
            case '*.tar.gz' '*.tgz'
                tar xv; or tar zxvf "$i"
            case '*.tar.bz2' '*.tbz' '*.tbz2'
                tar xvjf "$i"
            case '*.tar.xz' '*.txz'
                tar --xz -xvf "$i"; or xzcat "$i" | tar xvf -
            case '*.tar.zma' '*.tlz'
                tar --lzma -xvf "$i"; or lzcat "$i" | tar xvf -
            case '*.tar'
                tar xvf "$i"
            case '*.gz'
                gunzip -k "$i"
            case '*.bz2'
                bunzip2 "$i"
            case '*.xz'
                unxz "$i"
            case '*.lzma'
                unlzma "$i"
            case '*.z'
                uncompress "$i"
            case '*.zip' '*.war' '*.jar' '*.sublime-package' '*.ipsw' '*.xpi' '*.apk' '*.aar' '*.whl'
                set extract_dir (string match -r "(.*)\.[^\.]*\$" $i)[2]
                unzip "$i" -d $extract_dir
            case '*.rar'
                unrar x -ad "$i"
            case '*.7z'
                7za x "$i"
            case '*'
                echo "extract: '$i' cannot be extracted" >&2
                set success 1
        end

Finally, we’ll remove the original file if we’ve successfully unarchived the file, and end the loop and the function.

        if test $success -eq 0; and test $remove_file -eq 1
            rm $i
        end
    end
end

This was my first experience trying to port a larger function from zsh to fish, and it definitely took some playing around with the various test functions to get it right. Also, the string match functions were largely cobbled together from StackOverflow. I strongly suggest aliasing this function to x, or some other short sequence, for easier usage.

And voilà, we have a working general purpose extraction function, in fish!

🐠

Just an introductory post here, nothing to see.