For quite a while, I've been using the vim-ps1 plugin for Powershell syntax highlighting.  It's generally fine, but I have one annoyance with it: When I open a Powershell file, the plugin opens a horizontal split with a Powershell terminal in it.  That's...fine, but most of the time I don't want that.  And the documentation doesn't say anything about it.

Well, fortunately there's a resolved Github issue with the answer.  Turns out the issue isn't actually with vim-ps1, it's with coc-powershell, which actually does mention this issue in the docs.  Why the language server is popping up a terminal window isn't clear to me, but the solution is to add this to your coc-settings.json file:
"powershell.integratedConsole.showOnStartup": false

Easy fix!  Unfortunately, I can't check that into my vim-config Git repo because I have my Intelephense license key in that file, so I need to document it someplace else.  Hence this post.

As an aside, before scouring the web for that answer, I tried asking Claude.  That didn't go well.  It's first answer was to "look at your Vim config" or try disabling plugins, which was not even remotely useful.  When I pointed that I knew there was a setting for this, it asked me where I saw it.  If I remembered that, I wouldn't need to ask the AI!  At that point, I decided it was easier to do this the old-fashioned way and ended up checking the Github issues and found the solution in a couple of minutes.

Things like that make me appreciate William Bernstein's comments in his interview with Rob Berger.  When asked about using AI in his writing and research, he said that AI is extremely useful, but it's kind of like having a very dumb graduate assistant.  That seems about right to me.  Even a dumb grad student is still smart enough to get into grad school, so they're capable of doing some very helpful work, but they still have some significant limitations.

But the other night I was playing around with my attempt to learn Go by writing a NES emulator.  I'm working from a demo of writing one in Rust, which recommends having highly comprehensive unit tests, so that's what I'm trying to do.  The problem I'm running into is that this results in lots of repetitive test cases.  The individual test cases are short, usually six to ten lines, and take the form of a struct defining the processor state and expectations.  The thing is, there are a lot of them.  By that, I mean that so far I've implemented 20 of around 150 opcodes and my unit test file is already pushing 1000 lines, compared to about 250 lines of production code.

Now, a 4:1 test to prod ratio isn't necessarily a bad thing, but it does seem a little high.  And the tests are all very similar, so they're kind of hard to read and navigate - unless you know the exact term to search for, they all just blend together.  So I really wanted to condense them down, preferably to one line per test case.  So I finally decided to make a few functions to extract the common stuff into a template so that I can condense all those structs down into one-liners.  Great!  But I already have 1000 lines of code to update.  Not so great.

Enter the Vim macro reorder.  For each opcode, a wrote a function to create the test template.  Now I had to take the existing structs and convert those into function calls.  Unfortunately, this was too complex for a simple substitution and it was just too tedious to do that many by hand.  However, the exact same series of steps could be repeated for each test case, so I decided to look up that macro recorder that I've been accidentally turning on for years.

Turns out it's super simple.  You just start recording by using "q" with a register name (e.g. "qa") in command mode, do a bunch of stuff, and then run "q" again to stop.  Then you can execute the macro with "@" and the name, e.g. "@a" and repeat that with "@@".  By itself, this is not terribly remarkable.  But with Vim movements and actions, it's really easy to make a macro that performs a complex manipulation on structurally identical blocks of text.  So I was literally able to start recording, just do the manipulation like I normally would, and then stop recording, leaving me with a macro that works perfectly with basically zero extra work.

Like I said, nothing really new or ground-breaking here.  Just discovering one of those handy features that I've never really used before.  But now I know how to take advantage of that for future use.

At work, we have a PHP project that has automated integration tests written in Python.  The top-level directory of the Git repo is the normal PHP stuff, but the tests/integration/ directory is a Python sub-project that uses Poetry and Pytest.

Now, I use Vim as my editor and CoC with Intelliphense and Pyright for my PHp and Pythong language servers.  Since the main repo is PHP, Intelliphense works just fine.  Hwoever, Pyright needs a little help.  In particular, it didn't find the third-party dependencies or the integration test framework packages because it didn't know where to look.

Fortunately, this is easily fixed by creating a pyrightconfig.json file.  I was able to create one of those in the top-level directory of the project and add an "execution environment" to tell Pyright where to find the root of the Python project.  I set it to the "tests" directory because, while the main dir is tests/integration/,  that directory is also a Python module, so using "tests" lets Pyright find the "integration" module.

My particular file looks like this:

{
    "venvPath": "tests/integration",
    "venv": ".venv",
    "executionEnvironments": [
        {
            "root": "tests
        }
    ]
}

Naturally, most of the editing recommendations for Typescript are focused on Visual Studio Code.  But I like Vim, so I did a quick search and found this article, which led me to CoC (which I choose to pronounce "coke", like the soda), which stands for the slightly ungrammatical "Conquer of Completion".  It's a plugin for NeoVim and Vim that essentially does Intellisense (code completion, context popups, etc.) using language servers.

If you're not familiar, the Language Server Protocol (abbreviated LSP, though that always makes me think of the Liskov Substitution Principle) was developed by Microsoft for VS Code.  It's essentially a way to make Intellisense work without the editor having to implement support for each language.  It does this by defining a protocol that "clients" like an editor can use to communicate with a "language server".  The language server is a stand-alone program that can provide code intelligence for a particular language, but is not directly tied to any particular editor.  The server can then be called by any client that implements the protocol, which means that the editor itself doesn't actually have to know anything about the language to implement advanced editing features - which is huge.

Anyway, CoC is an LSP client for Vim.  And I have to say, it's awesome!  I've messed with a few code completion and LSP plugins in the past, but I never really got them to work right.  They were either difficult to configure, or required Vim to be built with particular non-standard options.  But CoC was dead-simple to set up.  The only catch is that you have to install the language servers separately, but it turns out that's super-simple as well.  (The ones I've used so far can all be installed through NPM.)

I'm still getting used to it, but having CoC is a game changer for Vim.  I'd given up on having this level of intelligence in my editor.  I mean, for something that supports as many languages as Vim, building it the old-fashioned way just isn't feasible.  But when you can use the same language servers as more modern editors to do the heavy lifting, suddenly it's no longer crazy.

The next step is to look into the available commands and customizations for CoC and see what I can come up with to optimize my experience.  So far it's a pretty cool tool and it definitely makes the development experience nicer.  I want to see what else I can do with it.

But one of the things that PHPStorm did automatically, which was quite handy, was to add PHPDoc comments to functions automatically.  This is kinda nice because, let's face it, unless you're writing a long description, most of a docblock is just typing.  You duplicate the parameters and return signature and, if the names and types are pretty obvious (which they should be), then there's not really much to say.  But having them is part of the coding standard, so you can't just skip them, even though they don't add much.

Fortunately, Vim has a plugin for that, known as PDV.  It will read the declaration of a function (or class, or a few other things) and auto-generate a docblock for you.  This is nice, but the extension was a little out of date - it hadn't been updated to support return type annotations.  There was a pending pull request to add that, but it hadn't been merged.  I'm not sure why - apparently that repo is dead.

So I decided to just create my own fork and merge the outstanding pull requests.  Now I have a version that supports modern type annotations, which is nice.  While I was at it, I also added an alternative set of templates for NaturalDocs doc comments.  I use NaturalDocs for LnBlog, so I figured it would be nice to be able to auto-generate my docblocks there too.  All I needed to do as add a line to my Sauce config to change the PDV template path.

I don't have this problem when browsing the web, because Vivaldi has a setting to put a clock in the lower-right corner of the window.  So I thought to myself, "Self, do you think Vim can do that same thing?"

Well, it turns out it can!  In fact, there's even an article on it.  Of course, that's for putting it in the plain-old status line.  I'm using the airline plugin, so I had to tweak it a little.  Still, I was able to get the passable looking image above by putting the following in my .vimrc:

" Put the current date and time in the status line and keep it updated
let g:airline_section_z='%p%% %#__accent_bold#%{g:airline_symbols.linenr}%l%#__restore__#%#__accent_bold#/%L%{g:airline_symbols.maxlinenr}%#__restore__#:%v %{strftime("%b %d %I:%M:%S%p")}'
let status_update_timer = timer_start(1000, 'UpdateStatusBar',{'repeat':-1})
function! UpdateStatusBar(timer)
  execute 'let &ro = &ro'
endfunction

The timer update the time every second (obviously you can do longer if you want).  That's because, otherwise, the time won't update until you do something in the editor window.  This way it stays current, even if I'm not actively editing.

At any rate, this is another one on using Komodo with Vim emulation.  This was written on April 16, 2014, just a few days after the last one on the same topic.  These days I'm using Vim all the time, so none of this is relevant to me anymore.  However, it is a nice example of how it's possible to extend a good IDE to customize your workflow.

In this case Komodo is (or was) customizable using JavaScript, which is nice - lots of people know JavaScript.  The down side is that, to do actually useful thing, you also it also used XUL and SciMoz, the Mozilla Scintilla binding.  These are less commonly known, to put it mildly.

To be fair, Vim isn't much better on this score.  While it supports multiple scripting languages, the primary one is, of course, VimScript, which is...not a great language.  However, it's also quite old, quite well documented, and there are lots of examples of how to use it.  The VimScript API is also pretty stable, as opposed to Komodo, which was in the process of moving away from the XUL-based stuff when I stopped using it.  And really, a little VimScript will actually take you farther than you think.

In any event, I guess the idea is that it's good to know how to customize your editor, at least a little.  You know, sharpening the saw, knowing your tools, and all that.  Good stuff.  Enjoy!

Since upgrading to Komodo IDE, I've been looking a little more at customizing my development environment.  This is actually made somewhat easier by Komodo's "sync" feature, which will synchronize things like color schemes, key bindings, etc. between IDE instances via ActiveState's cloud.

Anyway, as part of this I've also been looking more at the Vim keybindings.  I've been a casual Vim user for a very long time, but I was never hard-core enough to do things like stop using the arrow keys or give up using ctrl+C and ctrl+V for copy and paste.  So now I'm trying to do just that.

Of course, Komodo's VI emulation mode is a pale imitation of what's available in Vim.  However, even that pale imitation is actually pretty good.  In fact, its even better than Komodo's documentation would lead you to believe.  In addition to the basic modal editing stuff, Komodo supports a decent range of movement commands, variants of change and delete commands, etc.  Basically, it supports everything I already knew about plus a lot more.  So now I'm trying to get that extra stuff into my muscle memory.

In the course of looking at some Vim command guides, I naturally came across some handy looking commands that Komodo didn't support.  So I'm going to try to fix that.

The first one is the reg command.  Vim's registers were something I hadn't really worked with before, but it turns out that they're not only pretty cool, but that Komodo actually has some support for them.  I only know this because the documentation mentions the key binding for the "set register" command.  However, it doesn't implement the reg command, so you can't actually see what's in any of those registers.

So, long story short, I fixed that with a macro.  Just create a new macro named "reg" in your "Vi Commands" folder in your toolbox and add the following code (this requires another macro, executed at start-up, containing the "append_to_command_output_window" function lifted from here):

var viCommandDetails = Components.classes['@activestate.com/koViCommandDetail;1'].
                                getService(Components.interfaces.koIViCommandDetail);
var count = new Object();
var args = viCommandDetails.getArguments(count);

append_to_command_output_window('');
append_to_command_output_window("--- Registers ---");

for (item in gVimController._registers) {
    if (args.length > 0 && args.indexOf(item) < 0) {
        continue;
    }
    if (typeof gVimController._registers[item] !== 'undefined') {
        append_to_command_output_window('"' + item + '   ' + gVimController._registers[item].trimRight());
    }
}

This allows you to type ":reg" and get a list of the current registers in the "command output" window in the bottom pane.

Another good one:

var scimoz = ko.views.manager.currentView.scimoz;
if (scimoz.selText.length == 0) {
    ko.commands.doCommand('cmd_vim_cancel');
} else {
    ko.commands.doCommand('cmd_copy');
}

This can be bound to ctrl+C and allow you to keep the default "copy text" behavior when there is text selected, and still work for Vim's "back to normal mode" when nothing is selected.

One of my favorite things about Komodo was that it had pretty good Vim emulation.  I started using that because a few years before I'd spent a lot of time going back and forth between a Windows PC and a Macbook Pro.  The Macbook keyboard had that weird Apple layout going and it routinely messed with me, so I eventually gave up and decided to use Vim-mode because that's the same on both platforms.

Of course, things have changed since then.  I've become a full-time Vim user, and have all the fancy faux-IDE stuff set up.  I actually like it so much that I stopped using PHPStorm for work and switched to doing all my development in Vim.  So this post is no longer relevant to me, but it at least has a few handy links, so enjoy!

I've been a Vim user more or less since I started using Linux.  Mind you, I was never really a hard core Vim user.  I still use the arrow keys, for instance, and manage to get by on maybe a couple dozen keybindings and commands.  I have no clue how Vim's scripting or configuration systems work.  All I know about ctags is that they're a thing that exists.  So really, I'm more of a dabbler.

The other part of this is that I like at least a small amount of IDE in my normal working-day editor.  I kind of like having some sort of "project view" of my files, a code hierarchy viewer, some form of Intellisense, etc.  And while you can get most of the stuff I like in Vim, they're not there out of the box.  And even if you can get them, you can't count on having an obvious graphical way to manipulate them.  Typically, you just have to read the documentation to find out what the key bindings are to trigger everything.

So the upshot of this is that I use Komodo IDE with the Vi emulation setting.  This essentially turns on a Vim emulation mode that makes the editor modal and enables a lot of the standard Vim keybindings as well as a small subset of common commands.  So I get Vim goodness with all the convenience of a full IDE.  I had never really looked closely at just how much of Vim Komodo would emulate, though - I just knew it supported everything I commonly used.

Well, I had some extra time after finishing all my bug fixes the other day, and since really learning Vim has been on my list of things to do for, er, over 10 years, I decided to look up some Vim reference sheets and see how many of the commands and keybindings actually worked in Komodo.  Turns out it was a pretty decent amount.  (Note from the future: I didn't write down the details at the time and don't care enough to catalog now that I no longer use Komodo.  Suffice it do say that Komodo's Vi emulation was actually pretty good.  Maybe not as good as IdeaVim, but pretty good.)

If you've used Vim casually or been around the UNIX world for a bit, you may have heard of ctags, but not really been sure what it was good for.  Well, ctags is a code indexing tool.  It scans a bunch of source code and creates an index of it.  The goal is the same as creating a  database index - to allow you to look up specific things quickly.

That's straight-forward enough, right?  But what the heck do you do with the index once you create it?  Well...nothing.  At least, not directly.  Sure, you can manually create and query the tag index from the command line, but you wouldn't really want to.  Following the UNIX way, ctags is really just one part of the pipeline.  It creates the index and it's your editor that queries it and does stuff with the result.

If you want to use Vim for any non-trivial development, then you really want to be using ctags.  It provides you with a handy way to jump between definitions of classes, functions, and so forth, much like you get with Visual Studio or PHPStorm.  It makes your life significantly easier.

The only problem is that there's a little setup that needs to be done.  Reading the ctags index doesn't require anything special if you're using the default "tags" files for the index.  However, generating that file takes a little more effort.  You can do it manually, but really you want it to happen automatically in the background.  Luckily, there's a plugin for that - Gutentags.  This plugin will basically just update your tags file in the background at appropriate intervals.  Although it has some options available, there's not really anything you need to configure for it - it just works out of the box.

Once you've got your tags file auto-updating, the next thing is to figure out how you want to browse tags.  The workflow that works best depends on your preferences, and I can't claim to have mastered it.  This page gives a good overview of the different commands and default keybindings that are available for tag browsing.  As with everything else in Vim, there are a lot of options available, but you can get by with just a few to start.  Personally, I find that just ctrl+] and :tselect work for 80% of my needs, but your mileage may vary.

If nothing else, the article gives you a good sense for just how powerful Vim is when it comes to extending its behavior.  It's actually pretty impressive.

Earlier this year,  finally read through The Pragmatic Programmer.  It's been sitting on my bookshelf for...at least 15 years now.  I'd read parts of it before, but never went through the whole thing.  Anyway, it contains a section on choosing an editor, and one of the things they stress is extension.  You need to be able to customize your editor to extend its functionality to suit your workflow.  The idea is that the editor is one of your primary tools of code-craft and you need to make it truly yours.  You need to learn to use it well and completely, to make it an extension of your hand.

So far I'm finding Vim to be a pretty good choice in that regard.  Partly this is due to its raw power, but to a large extent it's also due to its age and the ecosystem around it.  Vim is a very old tool and it's very mature and stable.  This is a very good thing, because it means that there are lots of examples and documentation for how to use and customize it.  If you want do do something new with Vim, there's a good change that someone already wrote a plugin to do it.  And if not, there are plenty of plugins out there that you can use as examples. 

Being mature and stable also means that things are unlikely to change out from underneath you.  Sure, new features are still being added, but the basic functionality has been largely unchanged for a while.  This is what you want from a good tool.  If you're going to invest a lot of time and effort to get good at using a tool, you want that investment to retain its value.  You don't want to spend three months every couple of years re-learning because the tool vendor decided to re-architect their product or switch to the latest trendy programming language.

So while Vim may be old and boring, there's something to be said for being old and boring.  When was the last time you saw an old, boring person on The Jerry Springer Show?  Doesn't happen.  New and interesting may be exciting, but there's a reason why telling someone "may you live in interesting times" is supposed to be a curse.