A common recommendation when using JavaScript is to put your <script> elements at the end of your HTML, including those that reference a JS file on your site. One issue, however, is that if you then have a script that references a function from another script, how do you ensure the other script is loaded already?

I have used S3 and S3-compatible storage for a long time now, and have used both s3cmd and the AWS CLI tooling to sync, either between buckets or with a local filesystem. It generally "just works".

Except that when it doesn't, it's really hard to debug.

I occasionally record screencasts for work — some of these are used for the website as demos/training material, and sometimes they're used internally by our various technical teams. When I record, I use OBS Studio, which works brilliantly.

However, since the last time I recorded, I've upgrade my operating system, as well as switched over to Wayland, and I discovered after doing a recording session that my audio was super choppy.

This is how I fixed it.

I use terminal-based programs a lot.

It should be obvious to anyone following my blog that I use editors in the vim family. But there are a slew of other tools I use from the CLI: docker, phpunit, phpcs, psalm, pandoc, ssh, ngrok, and more. Often, I'll be editing a file, and need to run another program, and reference what I'm editing: running unit tests, linters, or static analysis often fall in this category.

Sure, I could use a tabbed terminal, but then I can't have the results of running the program right next to the editor. So for this, I use a terminal multiplexer; specifically, I use tmux.

Being a fan of Markdown and text formats in general, but living and working in a society where other formats are more often used, it's convenient to be able to convert my files to formats others can use.

And there's really only one tool for that: Pandoc.

I'm a huge fan of Markdown. There's something elegant in using textual sigils to provide contextual information. I've used it for taking notes, creating RSS feed content, producing my blog, and even in emails (I soooo wish there were a way to convert markdown within Outlook for the web and GMail!)

So it should come as no surprise that I use a variety of tools to help me when writing markdown in (n)vim.

Because I've spent most of my professional life coding, I've also spent a lot of time using source control. I've been using specifically git for many years (even pre-dating the Zend Framework migration from Subversion). While I typically use a terminal multiplexer (for me, that's tmux; for others, that might be screen), and can move to another pane or create one quickly in order to run source control commands, doing so interrupts flow.

That's where vim-fugitive comes into play.

I've used vim and variants since 2001. In 2019, a friend introduced me to coc.nvim, which turned out to be my initial gateway to nvim, which I adopted a year or two later.

Yesterday, I discussed vim-surround. Today I'm going to discuss another plugin I've used a ton: tabular.

I've blogged about vim a number of times. I've been using vim or its descendents for 22 years now; I switched to neovim a few years back, but it's compatible with the existing vim ecosystem. (The primary differences, to my mind, are that it has a more optimized engine which is more performant, and that you can now configure and extend it using Lua if you want. Otherwise... it's just vim.)

I used to "collect" plugins, but at this point, particularly since switching over to neovim, I've reduced my plugins quite a bit, to only those I use on a regular basis.

So, I figured today, I'd start a mini-series as part of my Advent 2023 blogging, on some of my most used plugins.

Today's plugin: vim-surround.