I’ve been revamping my Neovim configuration (more on that some other time).

I used to have a fuzzy searcher of Qt and C++ docs in Vim which would open the thing I searched for in a web browser or Qt Assistant (or cppman, but that is cppref only).

That was tedious for a several reasons I’m not going to go into now, so I decided to use this Neovim configuration revamp to make shell-based documentation nicer.

Enter zeal-cli

Zeal is a really nice offline documentation browser that comes with more than 200 documentation sets. And you can also create your own sets. (for Qt users, imagine Qt Assistant, but with docs about everything)

Now, Zeal doesn’t have a nice CLI API, but the docset format is simple enough for it to be used even without the Zeal application (after you use it to download docsets you want).

And that is exactly what zeal-cli does.

It is a small python script that shows Zeal docs in the Lynx console web browser. It can also clean-up the html pages from noise like navigation menus, table of contents and other things that just take valuable space before showing them in Lynx.

Usage is quite simple – you specify the docset you want to use and which page to show:

zeal-cli cpp std::string

Fuzzy searching

zeal-cli can also list all the pages available in a docset which can be used along with an application like FZF for fuzzy searching the documentation. You can just pipe the output of zeal-cli to fzf to get a similar view to the screenshot above:

zeal-cli cpp | fzf --height=50% --preview='zeal-cli --lynx-dump=true cpp {}'

Neovim integration

I’ve also made a small Fennel-based plugin for Neovim and Telescope.nvim to be able to search and show the docs inside of Neovim. This plugin in action is what the screenshot above shows.

There’s room for improvement for both zeal-cli and nvim-telescope-zeal-cli and patches are welcome.

I promised gocryptfs support in Vault a long time ago, but I kept failing to deliver on that promise because of other obligations, life and work happenings.

Now, the beauty of Free Software is that the users do not need to rely only on my free time for new Vault features.

Martino Pilia sat down and wrote a gocryptfs backend for Plasma Vault which has been merged and will be available in Plasma 5.19. Many thanks for that!

As with all new things, you are advised to be cautious as there might be some bugs remaining we haven’t detected.

kdesrc-build is an amazing tool that makes building KDE projects a breeze.

Now, I like having several build profiles for the projects I’m working on. The main build done by kdesrc-build is done with gcc, but I keep also a parallel build with clang, and some builds that incorporate static analysis tools and such.

At first, a long time ago, I was doing all this with shell scripts. But that approach was not really scalable.

Then I wrote a small tool that builds on kdesrc-build, but allows you to define different build profiles.

This tool has now been updated and moved to KDE’s brand new GitLab instance at https://invent.kde.org/ivan/kdesrc-build-profiles.

It allows you to create a few profiles, and specify which projects you want built with each of them. So, for example, you can keep parallel builds of plasma-workspace with gcc and the latest clang, while having a static analysis tool being run on plasma-framework and plasma-vault.

The example configuration file comes with the program. The format is the same as the one used by kdesrc-buildrc, just with a few custom fields.

Compilation database

In recent times, quite a few C++ IDEs or editors use clang behind the scenes to give you code completion, quick fixes, etc. It is often needed to create the so called compilation database which contains the compiler flags used to compile your project in order for the clang integration with your editor/IDE to work properly.

I found it quite tedious to always have to set this database for all the projects that I work on.

Because of this, kdesrc-build-profiles has got a new feature – it can now symlink the compilation database generated by cmake to the root of your project’s sources where the editor/IDE will find it easily. You just need to add symlink-compilation-database yes to the kdesrc-build-profilesrc file, and run the tool.

Installation

The program is written in Haskell. In order to install it, just install the stack package manager and do this:

stack update
stack install kdesrc-build-profiles

If you are old-school and use cabal instead of stack, the installation is similar:

cabal update
cabal install kdesrc-build-profiles

If you want to compile it yourself, the steps are also easy:

git clone https://invent.kde.org/ivan/kdesrc-build-profiles.git
cd kdesrc-build-profiles
stack build
stack install

Usage

To use it, copy the kdesrc-build-profilesrc-example (remove the -example suffix while doing so) file into the KF5 sources directory (where you keep kdesrc-buildrc file), edit it to fit your setup, and run it.

The commands are quite simple. For example, if you want to build all projects you configured under clang profile, do:

kdesrc-build-profiles clang

If you want to build only plasma-desktop and plasma-workspace with clang, do this:

kdesrc-build-profiles clang plasma-desktop plasma-workspace

For more commands, use the --help.

Qt has a long history. The first stable version was released before the first version of C++ was standardized and long before the different C++ compiler vendors started shipping usable implementations of the C++ standard library. Because of this, Qt often followed (and still follows) some design idioms that feel unnatural to the usual C++ developer.

This can have some downsides for the Qt ecosystem. The evolution of the C++ programming language which sped up quite a bit in the last decade often brings improvements which don’t fit well with the Qt philosophy. In this blog, I offer some ways to work with this.

Range-based for loops

C++11 brought us the range-based for loop which allows easy iteration over any iterable sequence, including common containers such as std::vector, std::map, etc.

for (auto name: names) {
    // ...
}

When you write code like the above, the compiler (C++11) sees the following:

{
    auto && __range = names;
    for (auto __begin = begin(names), __end = end(names);
              __begin != __end; ++__begin) {
        auto&& name = *__begin;
        // ...
    }
}

It takes the begin and end iterators of the names collection, and iterates from one to the other.

I’ve been playing around with type meta-tagging for my Voy reactive streams library (more on that some other time) and realized how useful it is to be able to check whether a given type is an instantiation of some class template, so I decided to write a short post about it.

Imagine you are writing a generic function, and you need to check whether you are given a value or a tuple so that you can unpack the tuple before doing anything with it.

If we want to check whether a type T is an instance of std::tuple or not, we can create the following meta-function:

template <typename T>
struct is_tuple: std::false_type {};

template <typename... Args>
struct is_tuple<std::tuple<Args...>>: std::true_type {};

The meaning of this code is simple:

• By default, we return false for any type we are given
• If the compiler is able to match the type T with std::tuple<Args...> for some list of types, then we return true.

To make it easier to use, we can implement a _v version of the function like the meta-functions in <type_traits> have:

template <typename T>
constexpr bool is_tuple_v = is_tuple<T>::value;

We can now use it to implement a merged std::invoke+std::apply function which calls std::apply if the user passes in a tuple, and std::invoke otherwise:

template <typename F, typename T>
auto call(F&& f, T&& t)
{
    if constexpr(is_tuple_v<T>) {
        return std::apply(FWD(f), FWD(t));
    } else {
        return std::invoke(FWD(f), FWD(t));
    }
}

Up one level

The previous meta-function works for tuples. What if we needed to check whether a type is an instance of std::vector or std::basic_string?

We could copy the previously defined meta-function, and replace all occurrences of “tuple” with “vector” or “basic_string”. But we know better than to do copy-paste-oriented programming.

Instead, we can increase the level of templatedness.

For STL algorithms, we use template functions instead of ordinary functions to allow us to pass in other functions as arguments. Here, we need to use template templates instead of ordinary templates.

template <template <typename...> typename Template,
          typename Type>
struct is_instance_of: std::false_type {};

template <template <typename...> typename Template,
          typename... Args>
struct is_instance_of<Template, Template<Args...>>: std::true_type {};

template <template <typename...> typename Template,
          typename Type>
constexpr bool is_instance_of_v = is_instance_of<Template, Type>::value;

The template <template <typename...> allows us to pass in template names instead of template instantiations (concrete types) to a template meta-function.

We can now check whether a specific type is an instantiation of a given template:

static_assert(is_instance_of_v<std::basic_string, std::string>);
static_assert(is_instance_of_v<std::tuple, std::tuple<int, double>>);

static_assert(!is_instance_of_v<std::tuple, std::vector<int>>);
static_assert(!is_instance_of_v<std::vector, std::tuple<int, double>>);

A similar trick is used alongside void_t to implement the detection idiom which allows us to do some compile-time type introspection and even simulate concepts.

I’ll cover the detection idiom in some of the future blog posts.