While reading about setting up Neovim, I kept coming across guidance to install the nvim-lspconfig plugin. The gist of the advice was that installing this plugin was essential to using LSP in Neovim. It made it “easier” somehow.

As I wanted to avoid plugins where I could, and I only needed to configure three or four language servers (out of the dozens nvim-lspconfig supports), I wondered what the plugin actually did and whether it was worth pulling into my configuration.

In this post, we’ll look at getting a language server working with an open file without using any Neovim plugins at all. We’ll get to the point where we can open .go files in a Go module, and automatically be able to use LSP functionality like go-to-definition, auto-complete and rename.

Then we’ll look at nvim-lspconfig with fresh eyes, understanding what it’s doing and better able to judge whether it’s worthwhile for my, and your, configuration. Regardless of the conclusion we come to, for me it’s always super-valuable to understand what’s going on under the hood of my tools, and we’ll certainly come out of this article knowing a lot more about Neovim’s LSP API and capabilities than I did before I started writing it 🌟

This site is a static site, pre-built with Hugo and uploaded to GitHub Pages. Static sites do not appear to lend themselves to dynamic functionality, like scheduling posts for later, automatic publication. This is what I believed; I had to be there, at the keyboard, bashing out commands, to upload a new version.

But with a little creativity, it can be done.

A couple of weeks after I started to use GitHub Actions to publish this site, I had three or four posts half-drafted (a result of my goal to post smaller things, less often). I wanted to get them finished, but I thought it’d be good to publish them over time rather than all at once. Idly, I wondered whether Hugo could schedule posts, and thought, “no, of course not, I have to run Hugo”. It was then that it hit me that I’d just got “running Hugo” automated within an Actions workflow. And that Actions must have a way to schedule regular execution of a workflow. A plan for scheduled posts was born.

I’ve been using this setup for a couple of months now to schedule publication. It’s simple and reliable. This post shows how to set this up for any GitHub Pages site that uses Hugo. While this post talks specifics for this setup, I expect the general idea can be made to work with any CI/CD and static site builder.

The outline for this is:

1. Set up a GitHub Pages site to be built using Hugo and published nightly using GitHub Actions.
2. Show how to write a Hugo post for future publishing. It’ll be caught and published during the nightly scheduled build, but not before.

Let’s get started.

It’s twenty years — and one day — since I wrote the first post still available on this blog, the memorably titled 48 - null. Early posts only got a number, addressed by their ID using something like index.asp?post=48. I’m not sure exactly when the first post was written, as the first 47 posts disappeared after a SQL injection attack. So we’ll go with that 48th post in 2003 as the honorary start date.

The null suffixes got appended by one migration or another between technologies , and I’ve never quite had the heart to remove them. Although I have updated titles when I’ve had reason to edit or clean up a post for other reasons.

Anyway, I don’t really have something big to say about twenty years of writing. I expected to be better at writing by this point. But it still takes ages to write anything longer than a few paragraphs, and I still struggle to pin down in words what I intended to capture. And I still overuse hackneyed phrases.

I’ve learned it’s relatively quick to write “instructional” posts — perhaps that’s where practice is most effective — but hard to write posts that try to capture a feeling. Most recently I found that with Modern Vim, part of which tried to capture some of the joy I had rediscovering Vim via Neovim. Using words to describe inner worlds is exquisitely difficult.

I’m pleased to have resolved to write more this year, and to accept that I can write smaller, less weighty posts. I have been successful in this. I’ve already written more posts in 2023 than I did in the five preceding years put together. Perhaps that’s the best way to celebrate twenty years. Just get writing again.

The requirement I had was to be able to open macOS Finder in the folder of the file that I was currently editing. I use this a lot when writing posts for dx13. As images live in the same folder on disk as the post they are used in, it’s useful to be able to quickly flick to the folder and drop an image there for use in a post.

The code itself is pretty simple. I’ll put it here. If you are here just for the code, you can grab it and be on your way. Put this code anywhere in your config:

vim.api.nvim_create_user_command('Rfinder',
    function()
        local path = vim.api.nvim_buf_get_name(0)
        os.execute('open -R ' .. path)
    end,
    {}
)

The interesting part is the story of how I got to the code. Exposing this functionality in Neovim was a small epiphany for me in understanding how vim is different from VS Code, my previous editor:

While Neovim is a powerful editor of itself, configuring it isn’t selecting from a static set of choices, as with VS Code, but instead a way of evolving the editor’s functionality to meet your needs. Adding small bits of function in that configuration is completely normal, unlike in VS Code where an extension is needed.

Perhaps reading through my thought processes will help this click for someone else starting out (for a second time, in my case!) with Neovim.

One of the things I’d not really considered about the crypto-mining craze of the last few years was its out-sized effect on the market for components:

One of the perks of normality largely returning to the PC components market now that the crypto mining bubble has popped has been a big improvement in component availability. Video cards were of course the biggest change there – even if prices on the latest generation remain higher than many would like to see – but crypto farms were also soaking up everything from CPUs and RAM to power supplies.

It’s obvious once you’ve been told about it. It’s fascinating to think of the sheer quantity of parts that these mining operations would’ve required. It’s depressing too, given the vacuousness of the market.

I wonder whether the new craze in AI model training will soak all these components back up again.

Via Anandtech.