The bestest autocomplete for Vim

TL;DR: I like YouCompleteMe

A post in Hacker News drew me to look at autocompletion in Vim. After trying a few plugins years before, I settled for the available-by-default autocomplete in Vim. It’s pretty dumb, but pretty dumb covers 90% of what I need: autocompletionForReallyUglyOrLongNames.

Vim’s omnifunc completer is enough if no fancy features are necessary: fast, available, trivial to setup. I have successfully used omnifunc in fairly large projects, and while it requires familiarity with the codebase, some may argue that’s a feature and not a bug.

Now I confess: I don’t understand Vundle, Pathogen or any other Vim plugin handler. Second extravagant opinion in this post: I don’t see the point of a plugin manager for Vim. I like knowing the source code of every plugin I use well enough so I can troubleshoot it when it breaks (*). I prefer to #include (or, rather, source) them manually. Keeping everything in Github, I rarely need to set up a plugin twice. The effort to install and configure a plugin is usually not a lot more than learning how to use that plugin in the first place.

While being Vundle illiterate may have made my experience a bit more complicated than necessary, I still found the experience of installing autocompletion plugins quite horrible (#). Deoplete had me chasing dependencies all over the place and Conquer of Completion seems to require such specific setup of version and plugins that I didn’t even attempt to install it.

YouCompleteMe, though, was a pleasant surprise: its documentation explained how to install in three steps, and it is a mostly self-contained plugin. While YCM has a compiled dependency, setting it up is pretty trivial. It just works out of the box.

Took me years but I’m very happy to finally find an autocomplete plugin that “just works” for my basic Vim setup.

(*) For some reason, I only feel this way about Vim
(#) Disclaimer: Re-reading my own text, it may appear as I’m somewhat belittling Deoplete, CoC, Vundle, Pathogen, etc. That’s not my intention. I have the maximum respect for these projects. The engineering effort in them is amazing, and I know for a fact they make life easier for a lot of people. I’m just not one of them.


Howto: shutdown a TV with HDMI CEC Chromecast

That’s a long title just to say “how to turn off your TV”. Only I want to show how to do it even if you lost your remote control.

Chromecast can turn your TV on and off, as long as it supports something called HDMI CEC. Of course the Chromecast itself needs to be powered, i.e. you can’t plug it to a USB port in your TV.

The “on” part is easy: you just start casting something (your pictures, for example) and Chromecast automagically turns your TV on. The off part is a bit harder.

Turning off is, obviously, an implemented feature, as the Google assistant can do it. After some Wireshark sniffing, I couldn’t find any URL you can call in a Chromecast to turn off the TV. Some people invested more time on this than me, so I assume there’s just no simple way to directly use a Chromecast for this. Luckily you can use the Google assistant.

I wrote “simple way”. The following maybe doesn’t quite qualify as “simple”, but it’s not too time consuming. It’s certainly not elegant, but hey (as of the date I’m writing this article) it works.

How to turn a TV off using a Chromecast

Part 1: Set up the Google assistant SDK

There’s no easy way to make a Chromecast turn off a TV, so instead we’ll interface with a Google assistant, then ask the assistant to do it for us. There’s also no easy way to do this with an API, but the assistant’s voice recognition is actually quite good. Let’s start by installing the SDK:

    1. Follow the setup instructions for the Google Assistant library, with the changes described below.
    2. The assistant examples need a microphone present, but we’re not going to use it. If you don’t have one and you’re doing this in a RaspberryPi, just fake one by putting this in ~/.asoundrc:
      pcm.!default {
        type asym
        capture.pcm "mic"
      pcm.mic {
        type plug
        slave {
          pcm "null"
    3. The same may be needed for a speaker.
    4. Continue the setup guide: create a project in the Actions console. Register also a dummy model to download the json credentials.
    5. Follow the “Install the SDK and Sample Code” instructions. In May 2019, they work fine in a RaspberryPI 3 with Raspbian.
    6. Try running the sample code. googlesamples-assistant-hotword segfaults but googlesamples-assistant-pushtotalk works fine.

Part 2: Hack the sample to turn off a TV

You should now have the samples from the SDK running. At least those that don’t crash. If you have a microphone, you can ask anything you normally ask the Google assistant like… the weather?

The assistant can turn off your TV if you say “Turn off $Chromecast_Name”. But what if you don’t like talking to your phone?

I’m sure you expect I’ll reveal a nice, clean way to invoke the assistant and make it turn off your Chromecast. Sorry, that would take too long. There is a text interface for the assistant but I wasn’t able to have it running in less than 15 minutes, so these are your options:

  • Use festival. echo “$Google assistant command” | text2wave -o cmd.wav will generate a command that (often) the assistant can understand. If you don’t have such luck:
  • Just record yourself. Hackish? Sure, but if all you need is to shut down a TV, that’s enough. Important note: Record yourself in mono 16KHz. Otherwise the assistant may not understand the wav file. If you run “file command.wav” it should look like this:
    command.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 16000 Hz<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>

Whatever method you choose, create a wav file with the command you want to execute (i.e. “turn off $Chromecast_name) and put it in the directory where you installed the Google Assistant SDK.

Part 3: Throw your remote to the recycling bin!

You’re ready now. Goto the directory where you installed the SDK and recorded your voice command, then try this:

$ source env/bin/activate
$ googlesamples-assistant-pushtotalk --device-model-id $AN_ID_YOU_GOT_FROM_GOOGLE --project-id $YOUR_GOOGLE_PROJECT_ID --once --verbose -i ./command.wav

With a bit of luck that should shut down your TV.


Logo borrowed from CodingHorror



Say nice things

As software developers, we need to put much more emphasis on positive interactions with our peers. Engineering requires critical thinking. Looking for cases where something (code!) will break. Criticizing what we do, on the hope of doing it better, is a key and necessary aspect of our profession. However, even when done properly (already a hard enough job!) this practice emphasizes negative interactions. In a normal job, what would you say is the ratio of times you hear “this might be better if ..” vs “I really liked X”?

Saying “this was good” is hard. More often than not, it’s hard to even notice good code (and I’d go as far as saying that noticing good things is hard in general!). Unlike criticism, positive interactions don’t lead to direct improvements. No code will be enhanced by saying “I liked this solution”, though people may be more inclined to considering criticism if the positive aspect is also noted.

In the end, maybe someone just had a slightly better day because you said something nice. That’s already a small victory.

GCC instrumentation flag: slow everything down!

Here’s a nice gcc tip if you think your code is running too fast: instrument everything! (Ok, it may also work if you need to create a profile of your application but for some reason Valgrind isn’t your thing).

Compile with

g++ foo.cpp -ggdb3 -finstrument-functions 

You can get a list of symbols with nm and c++filt, or you can implement your own elf reader too for extra fun.


using namespace std;

extern "C" {
    bool g__cyg_profile_enabled = false;
    stack g__cyg_times;

    void __cyg_profile_func_enter(void *, void *) __attribute__((no_instrument_function));
    void __cyg_profile_func_exit(void *, void *) __attribute__((no_instrument_function));
    void cyg_profile_enable() __attribute__((no_instrument_function));
    void cyg_profile_disable() __attribute__((no_instrument_function));

    void __cyg_profile_func_enter(void *this_fn, void *call_site) {
        if (not g__cyg_profile_enabled) return;
        cout << this_fn << endl;

    void __cyg_profile_func_exit(void *this_fn, void *call_site) {
        if (not g__cyg_profile_enabled) return;
        cout << this_fn << endl;

    void cyg_profile_enable() {
        g__cyg_profile_enabled = true;

    void cyg_profile_disable() {
        g__cyg_profile_enabled = false;

int a() {
    return 42;

int b() {
    return a();

int c() {
    int x = b();
    int y = a();
    return x+y;

int d() {
    return c() + b();

int main() {
    cout << d() << endl;
    return 0;

VimTip: Search and f(replace)

Pre-tip: When using search and replace in Vim, you don’t need to use slashes

This works just fine:


Did you know $replace doesn’t have to be a literal expression? You can also use Vim functions! For example:


will replace every occurrence of ‘bar’ for its line number. You can get creative and use any other Vimscript function.

std::byte – great idea. Meh execution?

I love the idea of C++17’s std::byte. A data-type that makes it explicit we’re dealing with ugly low-level details? What’s there not to love! One thing only, turns out.

First, the good part: separating character (human) representation from binary (low-level) representation is brilliant. No implicit conversion between the two separates the domains very well and creates a much clearer interface.

The bad part: std::byte is really really strict. It only accepts other std::bytes as operands(*). You’d hope this would work

auto f() {
  byte b{42};
  return b & 0b11;

It doesn’t. std::byte only accepts other std::byte’s as operands. The design goal behind it is good, sure. In practice, I’ve noticed this means casts are not limited to the interface between low-level and rest-of-the-world: casts and explicit byte’s get sprinkled all over the place.

My prediction: most people will dislike the boilerplate std::byte adds and fall back to unsinged char’s, until the type restrictions in std::byte are relaxed. I hope I’m wrong though!

(*) Yes, with the exception of shift operations. That was a good design decision!

GitHub tip: Prefill a bug report

Getting feedback from users is hard. In a platform such as Android, with apps evaluated in a couple of seconds, it’s even harder.

While trying to get bug reports for VlcFreemote I found a neat GitHub trick: you can pre-fill a bug report by using url parameters. For example, check this link:

Awesome! Takes a second and makes life much easier for bug-reporters!

Happiest bug report

Something is wrong: I’m happy over a bug report!

A few years back I developed a VlcRemote control app for Android. According to this chart, I didn’t actually save any time doing so. The time I spent spent developing the app is more than the cumulative time I would have spent by getting up from the couch and manually controlling VLC. That said, not having to leave the coziness of a warm blanket in winter probably made it worth the investment.

Not long ago I decided to submit this app to F-Droid. I’m too cheap to pay the 20ish dollars for Google App Store, and since I don’t have any commercial interest I don’t see the point. I didn’t think I’d actually get any users there, but today I got my first bug report. So much happiness! You’d think I shouldn’t be happy about my crappy software not-working, but hey, someone actually took the time to try it out. Even more, someone cared enough to submit a bug report!

Open source rules!