Sal's

24 hours with Emacs (a hasty rant)

2026-07-11T00:00:00Z

The process I outlined at the top of my recent post on modal editing missed some steps, which are italicized below.

Pick Neovim back up after some number of months or years.
…
Wonder: Should I use Emacs again??
[30% chance] Try Emacs again. ← just finished
…

So yeah, I did that. Per the cycle, I was once again confidently moving away from modal editing, but I still wanted an editor I could run in the terminal. Yadda yadda, and I spent the last day feverishly re-learning Emacs.

But minutes ago I decided to bail on it, and here are some hasty thoughts in support of that decision.

Note: I’m about to complain a bunch about Emacs because I’m in a pissy mood about it. So I’ll say at the outset that I think Emacs is highly cool. Amazing, really. That’s why I come back to it every so often. If you’re an Emacs person, I respect and admire and am sorta jealous of you. That said…

My purpose for trying Emacs was to have a terminal-based editor that’s vaguely similar to a native macOS text editor. As you might know, macOS has many baked-in Emacs movements. See this post from Jason Blevins for some good details on this.

But the similarities between Emacs and macOS are vanishingly thin. Emacs goes so much deeper so quickly that, within an hour or so of getting reacquainted with it, the thought of using it “because it feels like macOS” was laughable.

Instead, I found myself studying all sorts of commands, patterns, philosophies, etc. that aren’t relevant to any other editor. (Kudos to Mastering Emacs for being a wonderful guide, btw.) Plus, while you certainly can run Emacs in the terminal and many do, most Emacsers seem to recommend running the GUI app for the best and fullest experience, so I started doing that.

And thus, my two justifications for trying Emacs — similarity to macOS and having a go-to terminal editor — went up in smoke out of the gate.

What other justifications are there? Fun. I think that’s the only indisputable one. There’s an upvoted Reddit comment somewhere that says that, but I can’t find it now.

And it is fun. Too much fun. That’s the problem. I got up at 5:30 this morning to study and practice Emacs. Two hours later, when my family woke up, I was annoyed that I had to stop. I remember this feeling from the last time I dove into Emacs years ago. It becomes all I can think about, creating a sort of persistent and irritable obsession. My wife notices and reminds me to be present with the kids. This is not good for me.

Emacs not more efficient or faster. No way. Not when VSCode or Zed or just about any “popular” editor pops up and lets you get right to work with minimal fuss.

I’ve said it before, but it’s relevant: I’m pretty damn fast at macOS text editing. I’ve been at it for over 20 years. This is why Vim feels kludgy, too, even once I’m starting to get fast at it.

Poke around Reddit and you’ll see comments like:

You learn Emacs once, and you have an editor for life. Who knows how long — what’s it called? Zed? — will be around? Emacs stands the test of time. Jesus was catching up on his RSS feeds in Emacs before the last supper, you know.

Sure fine okay. But once you’re fast at the macOS defaults, you’re pretty much fast at any editor that comes along. Zed gets blocked at work, and I switch to VSCode. I want a zero-distraction editor, and I hop into iA Writer. I need to write an email, and I do it in Gmail or Fastmail. They’re all different but feel similar enough to me. The basic cursor movements and edits work the same across all of them. There’s no huge learning curve or switching cost. Certainly nothing like the cost of learning Emacs.^[1] And that’s awesome. That’s freedom.

I know where Emacs and Vim mastery lead: wanting to do damn-near everything in your editor (or whatever you call Emacs 😉), and feeling some level of discomfort when you can’t. This is especially true for Emacs because it can actually do damn-near everything. That’s not a place I want to go, honestly. I see that as a constraint rather than a feature. See above re: freedom.

And good lord, the mental overhead of trying to learn Emacs at a deep level. It’s immense. “Just use the basics,” some say. But I can’t, not knowing there’s this ocean of nerdy tools and tricks just underneath. It’s like telling a hungry dog to ignore a t-bone steak.

Hot take: For my basic-bitch needs, VSCode’s git UI is just as good if not better than Magit.

Hot take: TRAMP sucks. Again, for my needs, and specifically compared to VSCode or Zed’s remote SSH features. I’m sure it was innovative and amazing at one point. But from my perch, TRAMP is slow, doesn’t remember remote projects, causes LSPs and such struggle, and doesn’t handle port forwarding. Sure, you can optimize it and customize it endlessly. It’s Emacs, after all! But out of the box, it doesn’t hold a candle.

Going back to terminals, I’m plenty happy with the integrated terminals in VSCode and Zed. They feel mostly like a “real” terminal pane in my emulator of choice. I like that I can toggle them so easily with Ctrl-<backtick>. Emacs’s terminal options work, but they’re kinda wonky by comparison. That’s probably why there are several different options — shell, eshell, vterm, etc. I’m sure I’d get used to one of them, but again, it feels like a regression.

(For a good time, run a TUI like lazygit inside M-x shell.)

The Emacs chords for navigating buffers, tabs, etc. are slower and clunkier than the equivalents across macOS. In my opinion. Again, I’m biased because the macOS stuff is in my bones at this point.

Emacs server and emacsclient are cool but confusing. I installed Emacs via the generally recommended homebrew-emacs-plus package. Sometimes Emacs.app would just … do nothing when I opened it. I assume a preexisting server process was stuck somewhere. And when I’d launch emacsclient, it would load its own frame (aka “window”) even when I instructed it not to, and that frame didn’t seem to have any of my init.el settings loaded.

This is about the point where I said, fuck this, it’s not worth it.

When I end up torn about a decision like this, and I often do, I try ask myself these two similar questions:

What’s the simpler choice?
What’s path of less resistance?

It became hotly evident that Emacs is not the simpler or less-resistant path in the TextEditorverse. Meanwhile, from this angle, VSCode^[2] is really hard to argue with.

Case in point: I just banged out this blog post very quickly with what felt like zero friction in VSCode. I wrote it at the “speed of thought,” as the Vim folk like to say in praise of their editor. I’ll now do the git stuff in a matter of seconds. If this is already so comfortable and fast for me, what else am I trying to find?^[3]

I’ll close by repeating: Emacs is amazing. In many ways I love it what it stands for. But it’s not healthy for me, not at this stage of life anyway, so I have to get mad at it in order to distance myself.

If you’re curious about Emacs or Neovim and trying make heads or tails of my ramblings, here’s my advice:

If you’re just wondering if one or the other will make you more productive in a general sense, back away slowly, then turn and run and don’t stop running until you’ve reached the Land of Whatever You Already Know. These editors are epic time-sucks, and you’ll be much more holistically productive just using what you’re already familiar with.

If, on the other hand, you have a specific, unfulfilled need, like editing code on remote servers, or you just want to learn and experiment and have a geeky adventure, by all means, go for it. They’re both extremely cool and so much fun when they’re not messing up your life.

Maybe that’s why so many Emacs folk are hung up on never having to learn another editor; they still have PTSD from learning Emacs. 😆 ↩︎
I’d have said Zed instead, but it’s quasi-blocked at work, so it’s now a path of significant resistance. ↩︎
Oh right, M-x enlightenment-mode. ↩︎

Making VSCode play better with Markdown over SSH

2026-07-09T00:00:00Z

For reasons I hope to get around to writing about soon, I’m once again toying with VSCode to edit my notes and blog over SSH over a proxy host. 🕺 In fact, I’m writing this very blog post that way. Isn’t that amazing??

See this post for some earlier thoughts on this sort of thing.

Anyway, I noticed that VSCode felt quite sluggish compared to Zed with the same SSH target. I noticed it especially with backspaces. I’d hit backspace several times and then type a letter, and some of the backspaces were so slow to process that they’d end up deleting the letter I typed after them. As you might imagine, that was annoying.

Zed, meanwhile, was perfectly snappy.

I tried various things to improve this, including tweaking ~/.ssh/config, but the fix ended up being a simple tweak to the very popular Markdown All in One extension, which I’ve had installed since the dawn of time.

This GitHub issue was a direct hit. I disabled these two keyboard shortcuts:

markdown.extension.onBackspace
markdown.extension.onEnterKey

And now things seem fine!

Note that those are names of keyboard-shortcut settings, not the app-wide JSON settings. (I hadn’t yet noticed trouble with the Enter key, but figured I’d get ahead of it.)

Looking at the issue referenced from the one above, I believe disabling these shortcuts will break the extension’s list-continuation feature. That’s fine for this blog. I don’t make many lists here.

Now that VSCode is working fine, I have n+1 options to choose from in my text-editing indecision. Yippee. 😆

Mixed feels on modal editing

2026-07-09T00:00:00Z

I’m at a familiar stage of my cycle with Neovim. It goes something like this:

Pick Neovim back up after some number of months or years.
It’s so fun! Feel the power, tweak the configs, install the packages, learn some more tricks. It’s nearly all I can think about.
Some weeks later, the honeymoon period begins to fade, and it starts to feel normal instead of new and shiny. Inevitably, something in my customized config isn’t working right, and debugging it feels more like a chore now than an exciting side quest.
[current status] Start to wonder, is modal editing really any better for my use cases?
Switch back to non-modal editing, embracing the Emacs movements baked into macOS. Feel content.
Eventually, get itchy feet and return to (1).

I write a lot, but not a lot of code. Most of my writing is note-taking, chat messages, emails, documentation, blog posts, etc.

I know it’s annoying to say “here’s what an LLM said” in blog posts, but … here’s what Claude said. I found it useful because it’s really flippin’ hard to find an unbiased opinion on modal vs. non-modal editing from humans on the internet.

Mode-switching overhead is genuinely worse for bursty, prose-heavy, or exploratory editing (writing docs, README updates, chat messages) than for surgical code edits. If a lot of your work is prose or config files rather than repetitive code transforms, the ROI on modal editing is just lower — that’s not a skill issue.

Insert mode in Vim is worse than a normal text editor at insert-mode things (multi-cursor, smart autocomplete UX) unless you layer on plugins that basically reimplement what other editors give you for free.

If you’re constantly context-switching between Neovim and a non-modal editor (which you are, with code-server as primary), you pay a tax every switch — your fingers do the wrong thing in the wrong app for the first few edits.

There’s no objectively correct answer to the question of modal vs. non-modal editing, but those thoughts from Claude vibe with what I’m feeling. Constantly hopping between modes starts to feel clunky after a while, like I’m tripping over shoelaces. And when I drop modal editing and just go with the macOS default movements I know so well, it feels like I’m being let off a leash. If I were spending all day in code, I’d probably feel differently.

Admittedly, a factor here is that I use Ctrl-[ to escape from insert mode. I do that because I already have Caps mapped to Control. But those extra keystrokes add up. I should try the Karabiner-powered option of having Caps be Escape when it’s tapped and Control when it’s held. Or maybe mapping right-Command to Escape. Or something more efficient. But that’s more third-party software to install and manage.

Which gets me back to: is it really worth it?

VSCode Remote-SSH setup hangs when using fish shell

2026-07-08T00:00:00Z

I previously mentioned that VSCode’s Remote-SSH feature wasn’t working with my jump-host-proxied server. Well, I think I figured out why. It wasn’t the jump host that was the problem. Rather, VSCode’s SSH plumbing doesn’t play well with my beloved fish shell. See this thread, for example.

I’ve spent a fairly comical amount of time coming up with alternative workflows, including some big ones I haven’t had the chance to write about yet, when all I needed to do to fix this was add the following to my ~/.profile and ~/.bashrc:

case $- in
  *i*) exec fish ;;
esac

That’ll switch to fish in an interactive shell and otherwise stick with bash, letting VSCode do its thing.

Luckily I had fun and learned stuff while building out the alternatives. Otherwise I’d be slightly horrifed atm.

Hello from my Supernote Manta

2026-07-08T00:00:00Z

I think my little VPS is OOMing

2026-07-07T00:00:00Z

My IONOS VPS has been suddenly going unresponsive lately. I told Gemini I have this VPS for editing files in Neovim, and it suggested I might be running out of memory, especially if I’m running a TypeScript LSP, which is known for hogging lots of resources. It seems to have happened at least a couple times when I’m editing a .ts file, so that’s a good theory.

Add a swap file

The first thing I did was add a swap file so memory can spill over onto disk if necessary. Gemini said to do this with fallocate or dd depending on your filesystem, but after looking into it, I decided to just use dd to be safe. See this Ask Ubuntu thread.

Here’s what I did:

# create the swap file
sudo dd if=/dev/zero of=/var/cache/swapfile bs=1K count=4M
# only root should be allowed to read/write the file, since it can hold sensitive data
sudo chmod 600 /var/cache/swapfile
# format the file as swap
sudo mkswap /var/cache/swapfile
# activate the swap file
sudo swapon /var/cache/swapfile
# check the swap status
sudo swapon --show
free -h

Apparently the swap file won’t automatically get re-mounted after system restart, so to fix that, I edited /etc/fstab and added this line to the bottom:

/var/cache/swapfile none swap sw 0 0

/swapfile is the swap file path.
none is the mount point (swap doesn’t get a standard folder mount point).
swap is the filesystem type.
sw is the mount options, telling the system this is for swap.
0 0 are the Dump and Pass options, used for filesystem backups and checks; swap doesn’t need them, so they are set to zero.

If you see any issues with any of the above, please email and educate me!

For some smarter people covering these topics, see:

I believe this will fix the OOM problem, but it’s got me thinking about alternatives to my current rig. More to come on that soon.

Two-sentence post: Mosh is cool

2026-07-03T00:00:00Z

My dumb-guy summary of Mosh is that it’s like SSH but feels almost like you’re typing locally and keeps your connection alive through internet blips, computers naps, etc. It’s fitting pretty nicely into my remote-dev rig.

Apparently I've used Todoist before

2026-07-01T00:00:00Z

As I mentioned, I signed back into Todoist this week to kick the tires. The next day, I got this email:

I knew I’d dabbled on and off over the years, but 19 years ago? Is that even possible??

Wikipedia says Todoist was created in 2007 as a hobby project. I guess I was an early adopter. And that I’m old.

Fish shell

2026-06-30T00:00:00Z

Fish shell, how do I love thee? Let me count the ways.

You give me the glory of autosuggestions with nary a line of config.

Your default prompt has all my favorite things.

Your command history stretches to the beginning of time.^[1] I considered Atuin, but why bother when I have you?

Your tab completion is my tireless assistant, searching and suggesting without distracting.^[2]

Your scripting language is a pleasant escape from murk of bash. POSIX be damned!^[3]

Your builtin syntax highlighting forestalls my otherwise steady stream of user errors.

Abbreviations, your improvement on bash aliases, expand when you type them, letting me know exactly what I’m running and popping the command into your history for posterity. And you have more bash-like aliases for those that want them.

You are the first thing I install on a new machine. Let’s grow old together.

For more praise from smarter peeps, see:

Julia’s post, The fish shell is awesome.
Her followup, Reasons I still love the fish shell.
- See also the HN discussion. Top comment: “I adore fish and can’t imagine ever switching back to zsh or bash.”
Paul’s post, The fish shell is amazing.
The HN thread, Command line tools for productive programmers. Top comment: “The single best improvement to my command-line workflow I’ve done in the last few years has been switching shells [to fish].”

(Email me more good stuff to add here and I’ll do it!)

As long as time contains 256,000 or fewer commands. ↩︎
I just learned while writing this post that you can hit Ctrl-s to search the completion list! <3 ↩︎
jk but also kind of. Though I think fish has gotten a little more POSIX-friendly over the years. ↩︎

Two-sentence post: Todoist on the brain

2026-06-29T00:00:00Z

It’s helpful when apps have a web version so I can access them from my work laptop, which I keep mostly clean from personal apps and data. And thusly, despite being a long-time Things fan, I find myself back on app.todoist.com this morning.

Making a custom Neovim filetype picker with mini.pick

2026-06-29T00:00:00Z

It took me a minute to find a good example, so I’ll post this in case it helps anyone else.

For you Vimmers out there, here’s an example of how to make your own custom picker using Neovim and mini.pick, part of the very popular mini.nvim plugin. In this case, I’m adding a picker to set the active buffer’s filetype.

local function pick_filetype()
  -- Grab the current buffer before firing the picker
  -- so we can update it later when we're inside
  -- the picker's buffer.
  local current_buf = vim.api.nvim_get_current_buf()
  -- Get the choices for the picker. In this case,
  -- all available filetypes.
  local filetypes = vim.fn.getcompletion('', 'filetype')

  -- Launch the picker with our custom choices and
  -- handler.
  require('mini.pick').start({
    source = {
      name = 'Filetypes',
      items = filetypes,
      choose = function(item)
        -- Handle the user's choice.
        vim.bo[current_buf].filetype = item
        -- (Optional) Pop a notification to help us
        -- know it's working.
        vim.notify("Set filetype to " .. item)
      end,
    },
  })
end

-- Add a keymap to run it
vim.keymap.set('n', '<leader>bt', pick_filetype, { desc = 'Pick filetype' })

I created this file with my code: ~/.config/nvim/lua/custom/filetype_picker.lua. And then I wrapped the code in a module. Unnecessary but possibly more idiomatic, and leaves room to add configuration parameters later. (If this is bad form, please email and educate me!)

local M = {}

function M.setup()
  -- (insert all the code from the block above)
end

return M

And then from init.lua or the like, invoke it like so:

require("custom.filetype_picker").setup()

Not too shabby. Cheers to echasnovski and all the other contributors for making such a great library!

Added a light/dark theme toggle

2026-06-28T00:00:00Z

My last post on color themes and subsequent dark-mode refresh made me want to add an easier way to toggle light and dark mode on this site.

In my new nav section, you’ll now see a theme switcher in the middle:

CSS vs. JavaScript?

I was originally hoping to implement this entirely with CSS, since I know a number of folks out there keep JavaScript disabled when they peruse. I got that working, but the downside is that it doesn’t stick. As soon as a new page loads — for example, when you click any link on my site — the theme reverts to whatever’s dictated by your system.

And so it came to pass that this site grew its first few lines of JavaScript.

Revealing the switcher

I don’t want to show the toggle if it won’t work, so I default to hiding it and then revealing it via JS. This way, if the user doesn’t have JS enabled, they won’t see the toggle.

My first implementation of this resulted in a brief flicker on page load as the JS unhid the button. That really bugged me, so I asked Gemini to help me come up with a better approach. Now, I put a .no-js tag on the entire html body:

<html class="no-js">

And I hide everything related to the theme toggler in CSS:

.no-js .theme-toggle {
  display: none;
}

Then, in the <head> section, I replace .no-js with .js via one line of JavaScript:

<script>
  document.documentElement.className = "js";
</script>

Et voila! If JS is enabled, the theme switcher is enabled before the browser starts painting anything in <body>. No more flicker. At least, that’s how Gemini explained it to me. If I’m misunderstanding, or if you know of a better way to do this, please email me. I’d love to learn from you.

Toggling the theme

The JavaScript toggle logic does two things: (1) sets a data attribute on the document that CSS can key off of, and (2) saves the setting in localStorage to persist it across page loads and visits.

Here’s the entire script at this moment:

const toggleAttr = "data-theme";
const storageKey = "theme";
const light = "light";
const dark = "dark";

function applyTheme(theme) {
  document.documentElement.setAttribute(toggleAttr, theme);
  localStorage.setItem(storageKey, theme);
}

// Edit: These two lines might create a bug (defaulting to light mode
// even if the OS is in dark mode). Need to revisit.
const savedTheme = localStorage.getItem(storageKey) || light;
applyTheme(savedTheme);

function setupListeners() {
  const toggleBtn = document.getElementById("theme-toggle");

  toggleBtn.addEventListener("click", () => {
    const currentTheme = document.documentElement.getAttribute(toggleAttr);
    const newTheme = currentTheme === dark ? light : dark;
    applyTheme(newTheme);
  });

  const osModeQuery =
    window.matchMedia && window.matchMedia("(prefers-color-scheme: dark)");
  if (osModeQuery) {
    osModeQuery.addEventListener("change", (event) => {
      const newTheme = event.matches ? dark : light;
      applyTheme(newTheme);
    });
  }
}

setTimeout(setupListeners, 50);

The setTimeout at the end is because JS can’t see the toggle element when the script first runs. I assume that’s because the page hasn’t been rendered yet? I need to look into that.

Meanwhile, in the Sass (I switched to Sass from vanilla CSS during this project because mixins felt like a cleaner way to handle theming):

@mixin light-mode {
  // define light-mode variables
  --bg-color: var(--light-bg);
  --bg-color-alt: var(--light-bg-alt);
  // ...
}

@mixin dark-mode {
  // define dark-mode variables
  @include gruvbox-dark;
  --bg-color: var(--dark-bg);
  // ...
}

:root {
  // ...
  // default to light mode
  @include light-mode;
}

// handle OS-level setting
@media (prefers-color-scheme: dark) {
  :root {
    @include dark-mode;
  }
}

// handle theme-toggle set to dark mode
:root[data-theme="dark"] {
  @include dark-mode;
}

// handle theme-toggle set to light mode
:root[data-theme="light"] {
  @include light-mode;
}

// Use the variables defined in light-mode and dark-mode throughout.
// For example:
html,
body {
  // ...
  color: var(--text-color);
  background-color: var(--bg-color);
}

Anyway, I’ve got more testing and cleanup to do, but I think it’s working. If you spot a problem, please let me know!

High contrast vs. muted color themes

2026-06-26T00:00:00Z

Are high-contrast themes like Modus “better” than the more muted vibes like Catppuccin, Tokyo Night, or my personal favorite, Gruvbox?

I assumed there was a correct answer to this question, but of course reality is more complicated. The benefits of high-contrast themes are perhaps obvious. You can more easily see the letter shapes, especially when there’s a lot of ambient light or glare. That’s when I tend to reach for something like Modus.

On the other hand, high-contrast themes can be fatiguing because you’re staring at brighter lights on the screen. They can also cause halation, where bright text looks like it’s glowing or bleeding into the surrounding background. Apparently this is even more common for people with astigmatism.

Muted themes address those issues by reducing glare and brightness-driven fatigue. But if the contrast drops too low, or there’s too much ambient light bouncing off the screen, that’s a different sort of strain.

I suppose the question comes down to what I’ll call the “net contrast” of the theme once you factor in your environment’s lighting. (Gemini referred to this as contrast disparity, but I’m not sure that’s correct.)

My takeaways

Given the variables, it seems smart to be able to switch themes depending on the conditions. In my case, I want to mostly live in a more muted theme like Gruvbox and then switch to a higher-contrast theme when it’s bright around me.

GUI text editors

Switching themes is trivial in editors like VSCode and Zed. They have shortcuts like Cmd-K Cmd-T to pop up a quick switcher, and the change is saved in your config. Boom. Done.

Neovim

You can quick-switch themes in Neovim with the command:

:colorscheme $name

And you can tab-complete the names. Pretty good.

Neovim will also figure out whether your system is light or dark mode and follow suit. It doesn’t actually ask your OS, but rather your terminal emulator via an ANSI escape sequence (OSC 11, apparently). Modern terminals like Ghostty, which I use, know how to respond to Neovim’s “question” with an RGB value, which Neovim then uses to determine whether it should set the background to light or dark. And since Ghostty restyles itself because on the OS setting, I can use my macOS-level light/dark mode to control the OS, my terminal, and Neovim. Pretty cool!

You can also force light or dark palettes in Neovim with :set bg=light and :set bg=dark.

You do need to install the themes first. In a simple case, this can look like:

vim.pack.add({
	-- ...
	"https://github.com/folke/tokyonight.nvim",
})

vim.cmd[[colorscheme tokyonight]]

If you’re getting wonky coloring, Neovim might not be detecting 24-bit color properly. You could try enabling it explicitly in your config to see if it helps:

vim.o.termguicolors = true

See :h 'termguicolors'.

Ghostty (terminal emulator)

Ghostty will on-the-fly switch between light and dark mode as long as you have them configured properly. My config currently looks like this:

theme = dark:Gruvbox Material,light:Gruvbox Material Light

Ghostty provides this handy command which pops up a searchable picker of its pantload of themes for perusal:

ghostty +list-themes

See the Ghostty docs.

A note on tmux

I noticed that my Neovim colors were subtly different when inside tmux. I fixed it by adding these lines to ~/.tmux.conf:

# Tell tmux to use 24-bit true color mappings
set -g default-terminal "tmux-256color"
set -as terminal-features ",xterm-256color:RGB"

And then restarting tmux with tmux kill-server. Apparently merely reloading the config file isn’t enough.

Thoughts on my blog’s color theme

While writing this post, I began appreciating the muted color schemes more deliberately and decided my blog’s dark-mode styling was too high contrast for my taste. I gave it a makeover with the Gruvbox palette. I’m not a designer; If you hate it or see anything broken, please email me!

Neovim rabbit hole

2026-06-25T00:00:00Z

I’m in the rabbit hole. I’m not sure if I’m falling or burrowing. Both, I think!

Current statuses:

Trying to write some blog posts. I have three or four new drafts. But I keep getting sucked into config reworking.
Doing most of my writing and config editing on my remote VM now. It’s going pretty well!
Pulling in configs from Mini.nvim’s MiniMax. There’s so much to explore. It’s fun and overwhelming.
- Following MiniMax’s lead by breaking out sections of my config into the plugin/ subdir, like this. Files in there get auto-loaded, apparently.
- Feeling torn between starting simple and adding one thing at a time versus diving into the deep end and then backing out the features I don’t want.
Faffed about with color schemes, landed on Gruvbox for dark mode (my old flame) and Nightfox’s Dawnfox for light mode.
Wondering if I should add a focus/zen-mode plugin for writing or just keep resizing my terminal window.
Learning how to dig around better in :help. For example, use Ctrl-] to follow a link, not gd as you might use to jump to a declaration in code.

Botsitting

2026-06-22T00:00:00Z

After yet another push from senior leadership, I’m finally getting around to trying to do something more interesting with our internal AI resources than just chatting with Gemini. Specifically, I’m using Antigravity and writing agent skills to query various databases, read my meeting notes, read the news, and smash it all together in the hopes of surfacing something interesting that I may otherwise have missed.

The results so far are encouraging; and, the effort is making me appreciate all the commentary around “botsitting,” which refers to all the work required to get the agent to do actually the thing and, critically, do it well enough to actually be better than whatever you were doing before. When you venture beyond the typical chatbot and code-generation use cases, the botsitting factor gets real.

The back-and-forth looks something like this:

Me: /news [this invokes me skill to read all the stuff and tell me what’s changed lately]

Agent: [Spins for seven-ish minutes.] Okay, I made that report for you! [blah blah blah]

Me: The report loads but doesn’t have any data in it.

Agent: [Spins for a bit.] I fixed the problem!

Me: The report has rows now but only some of them show timeseries data in the chart when I click on them.

Agent: [Spins] …

You get the idea.

The interesting and disconcerting thing compared to writing actual code is that I never get the sense that I’ve fixed a problem. When I fix a bug in code, it’s fixed, and I can move on. I might break it again later of course, but I have confidence that the bug isn’t going to magically reappear the very next time I run the software.

With agent skills, the bugs seem to come and go as they please. I figured I could just get more and more verbose and explicit in my skill instructions as the bugs arise, instructing the agent how to avoid each one next time, but it’s not that simple. Something that was working fine last time, like the aforementioned report, will suddenly stop working without any changes to the relevant instructions. It feels like I’m Mickey Mouse waving a magic wand each time I run one: I can sense the power at my disposal, but I’m not sure what’s going to come from it.

I’m glad that these skills are just a side quest for me. I feel for peeps whose jobs have become full-time botsitting.