News of movie or TV adaptations come and go all the time but today my io9 RSS
feed brought me a trio of titles that are directly related to my tastes:

• News that the Vampire Chronicles’s TV show seems to be coming for real
  via Hulu (I’m just sad Bryan Fuller isn’t involved anymore but
  apparently he’s good friends with the showrunner so it might still turn out
  pretty).

• Netflix announcing that they’re adapting a whole bunch of Millarverse
  titles (more here) in various formats.

• Amazon surprisingly picking up Tales from the Loop, the
  art-book-turned-RPG (more here), as a TV show.

Not only are those 3 opportunities for me to say things like “I liked it before
it was cool” and “the original material is better”, but it’s also 3 things
that will bring some additional cash (hopefully) to the original authors whose
work I enjoyed.

These days, adaptations can often bring, at best, a lot of geek backlash, but
I find that even if I don’t like the adaptation, I’m happy that it’s bringing
attention to the original material, and money to the original authors. It’s
almost always good news in my book, except for the uncommon case where those
original authors get fucked for some reason.

I recently came across Josef Sipek’s series of articles on setting up
a “modern Mercurial”. In the first post, he realizes that he was missing
out on a lot of the new features that had been added to our beloved hg
along the years, due to the maintainers’ policy of not changing the default CLI
behaviour.

I realized I had the opposite problem – my .hgrc is a loose collection of
snippets I gathered from all around the web, at various times, and as such it
has accumulated several layers of Mercurial history.

Extensions

The main thing to clean up was my list of extensions. I had 14 built-in
extensions enabled, several of which had been deprecated in favour of something
better, or incorporated in the core. Now I’m down to 8:

• color: self-explanatory… make it pretty.

• extdiff: lets you specify an external diff/merge tool.

• histedit: lets you shoot yourself in the foot, a.k.a editing history with
  a workflow similar to git rebase --interactive.

• pager: lets you specify a custom “pager”, i.e. the thing that stops the
  text from scrolling off the top of the screen, and lets you “paginate”
  a command’s long output, like hg log. This mostly saves you from always
  having to do hg whatever | less or similar.

• purge: adds a command for removing all untracked files. Useful sometimes to
  clean up temp files, .orig files, etc.

• rebase: this is a basic operation for DVCSes so go figure why this isn’t
  enabled by default, especially now that we have phases.

• schemes: super useful for making aliases of hosting providers like Github,
  Bitbucket, and even your own private domains.

• shelve: I used to use that, along with MQ, to manage my works-in-progress,
  but now that I’m using evolve (see below), I don’t really use it anymore…
  still, I prefer to keep it around.

I also have a few third-party extensions:

• hg-git: required for mirroring Mercurial repositories to Github.

• hg-onsub: run a command on all sub-repositories. I don’t use sub-repositories
  much anymore, since I figured they are a pain to work with, but it’s still
  occasionally handy to batch-pull/update sub-repos.

• hg-allpaths: run hg pushall and push to all paths in one go.

• evolve: enables the changeset evolution features that are inactive by
  default in the Mercurial core. This is totally awesome, and quite mind-blowing
  sometimes.

• terse-status: when you have a directory with lots of untracked files and
  nothing else, make hg status show you just the directory… not 3 pages of
  untracked filenames.

Logging

Nothing fancy here, really… I’ve cloned Steve Losh’s templates a long
time ago and never looked back.

Multi-plaform

One cool thing that .hgrc files have is support for including other config
files that may or may not exist, and support for environment variable expansion.

My .hgrc is actually generated by my Dotfiles’ install
script, but it includes the “real” hgrc (which you can see
here). At the end, I can include further configuration files, like
a “local” file that could contain secret or temporary stuff, and a platform
specific configuration file:

# OS-specific settings
%include hgrc-${OS}

# Local settings (if any)
%include hgrc-local

That’s how I keep things working between Mac, Linux, and Windows between home
and work.

I recently read this post by Nicolas Douillet about CPU caches and performance. I recommend it! Apart from being a nice, fairly easily digestable recap of how CPUs work when it comes to memory, it also taught me the existence of something I totally didn’t know about until now: the Translation Lookaside
Buffer.

It’s used to cache recently used mappings between physical and virtual memory. I had no idea that this stuff was cached, and that it therefore could have some important effect on performance.

So event though I spent most of my long Easter week-end doing random cool stuff, I still got to do some nerdy stuff – namely catching up with bugs and feature requests for Gutentags, which is my most popular open-source project to date.

The main new thing is that Gutentags is now using Vim 8’s job API (job_start() and the like), with a compatibility layer for Neovim’s own, sadly different (but older), job API. This doesn’t make Gutentags any more asynchronous than it was before, since I jumped through hoops to make it work correctly even before, but it does clean up the code in a few places:

1. No more need for a .lock file that indicates if the background job is running. This means less chance of Gutentags getting “stuck” because the lock file was somehow left behind incorrectly by a previous crash.
2. No more need for polling the aforementioned lock file… we can just wait for a job to finish.
3. As a corollary of the previous point, it’s now easy to force-refresh Vim’s status line and get real-time, correct indication of whether Gutentags is running in the background or not. See :help gutentags-status-line for more information on this.

Because I don’t want to support 2 code paths in the same file, the requirements for Gutentags have been bumped to versions of Vim/Neovim that have the job/*jobwait features… if you need to use Gutentags with Vim 7 for some reason, you can stay on the vim7 branch, which may or may not receive some bug
fixes in the future.

You can pull the latest changes from BitBucket or Github depending on which DVCS you prefer. Have fun!