Advent blogging, i.e. blogging about a specific subject every day between December 1st and December 24th, seems to be picking up steam quite a bit this year. In the previous years, FastMail was pretty much the only one in my feeds doing this but, ironically, as they stopped doing it this year, it’s been replaced by others like Micro.blog’s Manton Reece (although he’s only doing half of it) or Vimways.

Inspired by 24ways, another advent blog dating back a dozen years, Vimways is, as you might guess, about Vim!

I was flattered to have Gutentags, my little Vim plugin, mentioned in the 2nd entry of the blog, even if the Daniel Moch, the author, said he stopped using it a while ago. Since the various methods mentioned in the article are not all equivalent, I figured I would add some clarifications here.

This requires some basic knowledge about Vim’s tags feature-set, but thankfully if you’ve read the aforementioned Vimways article, you should know everything you need to.

Synchronization and scalability

Tags files contain the symbols of your codebase. As you work, however, symbols change – you add and remove methods, rename them, change their signature, etc. So, unless something is being done about it, the tags files slowly but surely get out-of-sync with the source code, until you can’t really jump around anymore (it’s common for me to keep a Vim instance alive for days on end!). Having something that can keep the tags in sync with code as you work on the latter is therefore important.

Now, most “simple” methods for managing tags files rely on running ctags whenever the tags file needs to be kept in sync with the source code. This works fine for most cases, because the codebase is either small (like in most utility/low-level libraries) or large but broken up in small pieces whose vast majority is excluded from the tags files (like most web development projects where all dependencies are in a node_modules-type folder).

For bigger codebases, however, this quickly breaks down because ctags takes a long time to run. It’s more efficient to only update the part of the tags file that relates to the code you’re changing, and leave the rest alone.

Gutentags does this by running ctags only on the file you just saved in Vim.

If you want to keep your tags management separate from the text editor, you can, like Daniel says in his article, use some file-system watcher to regenerate your tags… you can even use that file-system watcher to run Gutentags’ own tag generation script directly, passing the proper options:

cd /my/project
/path/to/update_tags.sh -s /my/project/file_that_was_written

Run update_tags.sh -?, or look inside the script’s source code, to see what other options are available. Even if you don’t use Gutentags as a Vim plugin, you might want to use its sh and cmd scripts!

Combining methods

One common problem with having Vim manage the tags file is that it doesn’t know when the codebase is being modified externally – mainly when pulling/merging/etc. files in your VCS.

To fix this, many Gutentags users actually combine Gutentags with Tim Pope’s Git hook-based. After all, there’s no reason not to have the best of both worlds, where you don’t need to remember to run :GutentagsUpdate! after a git pull, and where your tags don’t go out of sync when you write code
either!

It’s a DIY world

Vim is ultimately about being able to do things your own way, so hopefully you can find yet another cool method to manage your tags, in which case you can share it with us!

You might have heard by now that Stan Lee passed away (which, sadly, is another celebrity death that I care about).

The only time I saw him was at FanExpo Vancouver 2013. Here he is, signing my friend’s Spidey book. “Thank you very much for all the stories” my friend said. “Oh, you’re very welcome” Stan said.

A bit later, all the Marvel cosplayers gathered for Stan, and for a minute he kinda looked like a nerdy version of Hugh Hefner.

Farewell, Stan!

I recently published version 0.8 of Wikked, my plain-text-files/SCM-backed
wiki engine, followed immediately by a quick little patch release. Grab it as
usual with a pip install wikked -U!

Although there are a few interesting new things in this release, the more
important announcement here is the launch of the official website
running itself on Wikked! Head over there now and tell me if anything
looks broken!

Keep reading if you want more information about all this.

New and Improved

There is now a simple way to upload files to your wiki – both as global files
(uploaded to the _files directory) or as page-local files (uploaded next to
the current page’s file). It looks like this and yes there is room for
improvement 🙂

The permission system has been re-written to use a more standard ACL-type model. You can check out the help section on permissions for more information…

…which leads me to the new help pages. You can see them on the official
website, but they come bundled with any Wikked wiki, since they’re part
of the source code. As such, they’re read-only (although you can edit them and
submit a pull request if you spot a mistake!). You can access them from the
“Help” link at the bottom of any wiki page.

Another thing you might have noticed with that link to the help section on
permissions is that Wikked now generates links for each heading on a page.

Last but not least, I re-did the UX of the navigation menu so that it finally
works correctly on both desktop and mobile browsers.

The Official Wiki

The other big new thing is the official Wikked wiki, which runs on
Wikked (unlike the previous official project page which was just a static page
generated with my other big web project, PieCrust).

Right now it looks a bit like this:

There’s not much to say about this besides “it’s about time”. There’s not even
much on that wiki yet – most of the content comes from the aforementioned new
help pages.

I wonder how long it will take until somebody finds a security hole in Wikked
and adds a dick pic to the home page. Oh well, I’ll worry about that if Wikked
actually gets popular… and even then, if you really want to post dick pics,
you can already do that on the Wikked sandbox wiki or, well, anywhere
on the internet, really.

And that’s it! If you haven’t checked out Wikked yet, give it a go:

1. pip install wikked
2. wk init mywiki
3. cd mywiki && wk runserver

Enjoy!