Thorsten Zöller - Articles

Running Anki inside Xephyr

2023-02-26

Running Anki inside Xephyr

2023-02-26

Anki is a great tool for memorizing things, like words in a foreign language you want to learn. I am using it for memorizing Vietnamese words in my endeavor to learn Vietnamese.

I am currently running Anki 2.1.16 on OpenBSD 7.1. Unfortunately, quite often Anki freezes after using it for some time, without any advance notice. When this happens, I can no longer do anything except moving the mouse pointer. I cannot switch windows and not even switch to the console in order to forcefully quit Anki. Apparently, it crashes the whole system, and the only way out is a forceful reboot.

I do not know what causes this behavior or if there is any fix for it. It seems that I am not the only one experiencing this, but I have not yet found a solution to this behavior.

I did find a workaround, however: Running Anki inside of Xephyr(1) (a nested X server that runs as an X application and is part of OpenBSD base) seems to prevent it from freezing. The workaround involves three steps:

Launch Xephyr on display :1 (or any other display differing from your main display, which is usually :0).
Launch cwm inside the Xephyr window just created (it is necessary to run a window manager since Anki employs multiple windows in general; of course, any other window manager can be used as well).
Lauch Anki inside the Xephyr window.

For convenience, I have created a small shell script for executing these steps:

Xephyr -br -ac -noreset -screen 1920x1080 :1 &
cwm -c .cwmrc_xephyr -d :1 &
DISPLAY=:1 anki &

Of course, the value of the screen command line parameter of Xephyr needs to be adjusted to your screen size. Also, I run cwm in the Xephyr window with a specific configuration file.

It works well, but strangely, after a while cwm seems to stop running inside Xephyr. This is inconvenient because it makes it impossible to switch between different Anki windows. The solution is to simply restart cwm by manually executing the second line of the script again.

Obviously, this is not a real fix to the problem, but it works. Hopefully, Anki will get more stable in the future so that this workaround will no longer be needed.

The Melancholy of the Day

2023-02-11

The Melancholy of the Day

2023-02-11

A new day begins, in the dark, in silence. Everything is still asleep; there is barely any activity, any motion. It is a state of peace and serenity. There is nothing to accomplish, no hustle and bustle; everything is immersed in stillness.

Then, the sun begins to rise, and slowly the world awakens from its sleep. Not much is happening yet, but the new day is full of potential, full of opportunities. An atmosphere of departure prevails. Everything seems possible, nothing impossible. As the sun continues to rise, a tension develops, as the inactivity of the night wants to release itself into activity.

Around noon, when the sun is highest in the sky, the day is most powerful. Glittering light falls from the outside into the rooms; light which is so strong that it blinds. The day is now bursting with energy. Everything is possible, and no end of this state is conceivable.

But then comes the afternoon, and slowly, very slowly, the sun begins its descent. At first barely visible, it does not take long until it becomes clear that the day cannot maintain its power. First shades emerge, and the light is no longer as glittering as it was before; it is slightly dimmer now than just a short time ago. And it is constantly changing. It becomes ever softer and warmer the deeper the sun is in the sky. It still fills the rooms, but instead of dominating them, it becomes tender. The light immerses everything in dim, warm colors, and the shades become longer and longer. It is a mystical, almost magical atmosphere which now accrues.

But this change of light, of the mood, is accompanied by a certain melancholy, and the melancholy grows the longer the day lasts and the fainter the light becomes. The steady change of light, proceeding faster and faster, leaves no doubt that the end of the day approaches. Some time still remains, but it seeps away quickly, second for second, minute for minute. The time when the day seemed invincible is now long gone; long gone is the time when it seemed that the day would prevail forever. It is absolutely clear now that it will be over soon. It had just brimmed over with power, with self-confidence, with energy–but now it becomes weaker and ever weaker, and very soon it will be history and forever, irretrievably gone.

Michael W Lucas: “Ed Mastery”

2024-09-29

Michael W Lucas: “Ed Mastery”

2024-09-29

The average user may not think a lot about which text editor to use. For us, however, the choice of a text editor is a very serious matter.

I’ll admit it: I have always felt a little proud to be a vi(1) user (I even have a dedicated vi page on my website). After having read Ed Mastery by Michael W Lucas, however, I feel somewhat wimpy about it.

Only recently did I stumble across the book, and I was surprised that a book about ed(1) – “the standard Unix text editor” – even exists. Yet, I knew immediately that I would have to read it. The mere existence of a book about ed(1) was enough to convince me that it will be worth it.

And I was not disappointed (not that I had expected that…). Michael W Lucas’ style of writing is hilarious, and first and foremost, it is simply a pleasure to read.

Admittedly, I never really looked past vi(1) in the history of Unix text editors. I roughly new that ex(1) and ed(1) are predecessors of vi(1) and that they are line editors, but they always seemed a bit too peculiar and exotic to me to justify looking into them in more detail (mostly because they are line editors, stemming from a time when monitors were not yet common or even available – one cannot take a line editor seriously these days, can one?). While I always felt that no real progression has taken place in editor development since the advent of vi(1) (which explicitly includes editors like Vim or Neovim), I always implicitly assumed that vi(1) was in fact a progression from ed(1) and ex(1) (reflecting the progression from line printers to monitors for displaying output). After reading Ed Mastery, though, I am not so certain about it anymore. I thought vi(1) was the pinnacle of simplicity, beauty and efficiency, but maybe I was wrong all along.

A while ago, there was a great post titled Your problem with Vim is that you don’t grok vi. on Stack Overflow (read it if you haven’t yet!). It basically states that many of the features of Vim that are generally considered improvements over vi(1) (Vi IMproved, you know?), making it more “user friendly”, are in fact feature creep (visual mode? why?) and simply exist because users don’t want to take the time to get really familiar and acquainted with vi(1). It is the antidote to Antoine de Saint-Exupéry’s famous statement “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”¹

I am wondering if something similar could not be said about ed(1) as well: “Your problem with vi is that you don’t grok ed.”

In any event, after reading Ed Mastery, many known features from vi(1) will make more sense. And even though it is rather unlikely that most users will ditch their editor of choice right away in favor of ed(1) after reading the book, I am convinced that it will improve your editing skills (if you use an editor descending from ed(1), that is – otherwise, all hope is lost anyway).

In summary: Experiencing joy while reading the book and learning profound things along the way: What more could you wish for from a book?

Therefore my recommendation: Get the book, read it and grok ed(1), now!

Note: Peter N. M. Hansteen has already written a great review of the book several years ago, and actually I feel that there is not much I could add to it (apart from my casual ranting you spent the last couple of minutes reading). You should definitely read it as well if you haven’t!

I’ll happily admit that I do use Neovim. Have I ever claimed that I live up to my own standards, after all? ↩

How I Use Vim

2025-08-30

How I Use Vim

2025-08-30

First things first: This is a contribution to the first ever Vim Carnival, initiated by Hyde, and it is an honor to be part of it! A big “thank you” to Hyde for coming up with this great idea, organizing the carnival and hosting the first one!

Note: In the whole article, I am mostly using “Vim” as a general term referring to any Vim-like editor (i.e. it encompasses in particular both Vim and Neovim), unless otherwise stated.

My History of Using Vim – A Personal Account

When I first grappled with Linux in the mid-to-late 1990s, I was inevitably confronted with the question of which editor to use. There was a huge amount of editors to choose from, but I quickly learned that there were two editors which were mentioned much more than others, and those two editors obviously were vi and Emacs. I started playing around a little bit with Emacs, but soon I realized that it was not the right editor for me. I was looking for a tool which allowed me to edit text files, and nothing else. And Emacs definitely allows one to do a lot more than just editing text files.

Now it is certainly not my intention to revive one of the most famous holy wars ever. I completely understand if people use Emacs if this is the right editor for them (or any other editor, for that matter). For me, however, vi (or rather Vim at that time) turned out to be the right editor.

Its simplicity and minimalist appearance appealed a lot to me. I liked that the mouse played no role in using it. And I knew that there was no need for me to look any further.

I guess I was drawn to vi for the same reasons I was – albeit many years later – drawn to the OpenBSD operating system: I like things to be minimal. In particular, tools should do one thing only and do it well (the core of the Unix philosophy, by the way).¹

Once I started using Vim, I never felt any desire to switch to another editor, and it is now my editor of choice since more than a quarter of a century (and I am so fond of it that I even maintain a dedicated vi page).

So, How Do I Actually Use Vim?

I do basically all my editing and writing in Vim, from e-mails to my PhD thesis (and, obviously, this very article as well). I also do all of my programming in Vim (no need for fancy IDEs). It is suitable for minor editing tasks just as well as for large writing or programming projects, and it has never failed me. It is fast – really fast –, and plain vi is available on basically every Unix installation out there – no matter what flavor of Unix or what age it is.

I love that it is a modal editor. In contrast to most other editors, pressing a key does not automatically make the corresponding character appear on the screen – it only does if you happen to be in insert mode. Otherwise, it is interpreted as a command. This allows for pretty easy key combinations for most simple and elementary commands (in contrast to non-modal editors, where one always has to escape entering characters, which necessarily leads to more complex key combinations). I also love that commands are very logical in a specific way; one could argue that they form some sort of a language. I will not dive into the details here; that would make for an entire new article (or two or three…). It has been claimed that editing text in Vim is an almost Zen-like experience, and while I feel that this does not really do justice to Zen, I completely get what is meant by that statement.

I do not use any plugins, although there is a huge ecosystem of plugins available for Vim (and Neovim even declares itself a “hyperextensible Vim-based text editor” on its website). I simply do not have any need for them. While there are certainly plugins which aim at improving the editing experience, my impression is that many plugins try to make Vim into something more than an editor. As mentioned earlier, though, that was one of the major reasons for me not to use Emacs. I do not want Vim to be more than an editor. I want to have an editor – no more and no less, period.

Actually, I do not even care much about many of the improvements of Vim over plain vi (Vim is “Vi IMproved”, after all…). For instance, I never use visual mode. While it may be helpful when one is new to Vim² – and in particular when one is used to GUI editors allowing one to mark text –, it is probably not the most efficient way to accomplish most of the things it is used for. In fact, I would argue that it would be a good idea to use plain vi for quite some time before (potentially) moving on to Vim. Many people probably do not even know how to accomplish things in vi without resorting to the improvements Vim offers. Yet, I am convinced that many of those improvements are improvements only in a superficial way. All this is elaborated extremely well in a reply on Stack Overflow, Your problem with Vim is that you don’t grok vi. I suggest reading it to everyone who is using Vim.

So, in a perfect world, I would be using plain vi instead of Vim³, and actually this is what I did for a couple of years.⁴ There are some reasons, though, why I switched to using Neovim for most things. One reason is that multiple levels of “undo” is in fact a real improvement over vi. Besides, I hail from one of those strange countries where people like to draw little dots above the letters, so Unicode support is practically non-negotiable for me. Also, I do use syntax highlighting, though I consider it by no means necessary (contrary to what I used to believe before using plain vi exclusively for a while).

My .vimrc is very simple as well. While I am quite impressed by all the config files one can find on the Internet which are hundreds of lines long, and while I have a tendency myself to tweak config files way too much, I prefer to keep things simple here as well. Setting a few options fully suffices to make Vim behave the way I like.

Now, while one might get that impression, it is certainly not my intention to argue against using Vim and in favor of vi. While I do think that Vim has become rather bloated over time, I use it on a daily basis and am most happy with it. My point is to direct the focus on the beautiful core of Vim – which is pretty close to plain vi in my opinion, yet extends it in certain ways. I sometimes like to compare vi and Vim to C and C++:⁵ There is this beautiful, rather small and well-defined, yet immensely powerful language C. And then there is C++, which extends C by far, adding feature over feature to it. Both are used heavily, and there are certainly reasons for both; but in most cases, I would rather use C instead of C++ (if I used them at all…).

So, coming back to the subject of this article, the question of how I use Vim: I use it mostly the way I would use plain vi, but I also happily make use of those extensions I find useful – which are rather few, though. While I have used Vim for decades, I am sure I only employ a small fraction of the possibilities Vim – or even vi – offers. I might become more efficient by putting work into learning more subtle and intricate features, but I feel no real need for it. I know that, should I need a particular feature, I will most certainly find it – if not in vi, then in Vim. Most of the time, though, I am happy using a select set of commands in a more or less efficient way.

There is so much more to say about Vim (maybe in the context of another Vim Carnival?), but for now, I will close my ramblings about Vim with one last observation: I do not just use Vim – I enjoy using it, a lot.

A Simple E-Mail Reminder System Based on cron and at

2023-02-10

A Simple E-Mail Reminder System Based on cron and at

2023-02-10

Since I cannot keep everything I have to remember in my head, I need a reminder system. While I would prefer an analog system (ideally one that integrates with my system for keeping track of tasks), I have not found a satisfying analog solution so far.

I am not looking for a full-fledged calendar system. If I were, I would be using Remind or calendar.¹ But they offer way more features than I need.

I basically have two requirements for my reminder system:

It has to remind me reliably by e-mail about things a certain time in advance.
It has to be simple and have as few external dependencies as possible.

The solution I have come up with is almost too trivial to share: It employs cron and at to schedule reminders, which are sent as e-mails via a remote SMTP server when they are due.

The Setup

The system depends on the following ingredients:

A machine which is up 24/7 – for scheduling reminders for arbitrary times.² I am using a server hosted on OpenBSD Amsterdam.
smtpd – for relaying e-mails to a remote SMTP server.
cron – for scheduling recurring reminders (like birthdays).
at – for scheduling nonrecurring reminders (like one-time events, or events which recur in irregular intervals).
mail – for sending e-mails non-interactively.

On OpenBSD, all the required software is part of the base system; see smtpd(8), cron(8), at(1), mail(1).

Both cron and at basically take two kinds of data as input: A timestamp which specifies when something is to be done, and an action which specifies what is to be done at the specified time.

Regardless of whether a reminder is recurring or nonrecurring, I want an e-mail to be sent to me at the specified time. Therefore, the action in both cases is sending an e-mail to me reminding me of the given event. Since the e-mail needs to be sent non-interactively when the given time is reached, the mail utility is invoked, and the reminder text is passed to it as the mail subject (since they are usually short, I only specify a subject and leave the body empty; then I don’t even have to open the e-mail).

In order not to have to specify the non-changing details (like the e-mail address) for sending the mail each time, I employ a small script called mailrem which is basically a wrapper around mail which takes the reminder text as its argument:

#!/bin/sh

from="John Doe <john.doe@email.com>"
subject="$1"

echo | mail -r "$from" -s "$subject" "$from"

Finally, in order for mail to be able to send mails to a remote SMTP server, smtpd needs to be configured such that it relays outgoing mail to a remote server.

Usage

E-mail reminders are sent by calling mailrem with the specific reminder text as its argument, e.g.

$ mailrem "Prepare tax statement"

In order to schedule reminders for a specific time, mailrem is not invoked directly as above, but either by cron or by at, depending on whether the reminder is to be sent on a regular basis or just once.

Recurring reminders

Recurring reminders are scheduled by cron via corresponding crontab entries. Start editing the crontab file:

$ crontab -e

Then add an entry for each recurring reminder like this:

0 0 3 18 * $HOME/bin/mailrem "[Reminder] Paul's $(( $(/bin/date +\%Y) - 1976 )). birthday (1976)"

This entry would send an e-mail each year at midnight on March 18 with subject “[Reminder] Paul’s n. birthday (1976)”, where n is calculated each time the cron entry is triggered by subtracting Paul’s year of birth, 1976, from the current year obtained by the date utility.³

Nonrecurring reminders

Nonrecurring reminders are scheduled by at via corresponding atjobs. For instance, to schedule an atjob for midnight in three days:

$ at midnight + 3 days

When prompted, enter the action to be executed at the specified time like this:

> mailrem "[Reminder] Doctor's appointment at 9 am"

Then, press <Ctrl> + D to queue the atjob.

That’s it. A very simple system which does its job and is easy to setup and maintain.

Caveats

The system is certainly not suitable for time-critical reminders. This is obvious, since by nature the reminders are sent in an asynchroneous way (i.e. via e-mail).
There is no easy way to get a consolidated overview over all currently scheduled reminders. For recurring reminders, crontab -l could be used. Similarly, atq displays the queue of atjobs. However, the output of atq is pretty much unparseable (at least in the version which ships with OpenBSD). So one would have to manually extract the job ID from the output of atq and then do $ at -c <id> in order to see the content of the job.
Failures cannot easily be discovered in general, and there is no recovery mechanism. If, e.g., for some reason the cron daemon is not running at the time a reminder is due, it will not be sent and will subsequently be lost forever.

Man page of the OpenBSD version: calendar(1) ↩
In principle, of course, it is also possible to run the system on a laptop. The severe drawback would be that reminders were lost if the laptop were not running at the scheduled time of a reminder. One could use tools like anacron instead of cron. This would mitigate the risk of losing reminders, but the time they are sent would then depend on when the laptop is running (which may differ greatly from the intended time of sending). ↩
Man page of the OpenBSD version: date(1). ↩

My New Website

2021-06-20

My New Website

2021-06-20

Not long ago, I created my first website. It was a static website, just like this one. I wrote the content in AsciiDoc and created a small script which rendered the pages to HTML.

I was very proud of it.

The content was basically plain text with a little bit of markup and some meta data – a beautifully clear separation of form and content.

The script generating the site consisted of about 200 lines of Ruby code. It was simple, and it did its job.

But it turned out that I would spend far more time tweaking the script to generate the site than to write content. After all, it was easier and more fun than to think about what to write.

Also, the barrier to publish was too high: There were always a few steps to be done before any change could be published. Not many steps, really: Make some change, run the script, clone the respository for the site, delete its content, copy the output of the script to the repository, commit and publish it.

Yet too many, as it turned out.

So I ditched the script for generating the site and started anew.

This time, it’s just plain HTML. Everything is created manually. Sounds like more work, but it’s not. It’s a profound simplification.

This approach has its drawbacks, of course. The content is interspersed with markup – HTML is not really lightweight. It is not possible to make a change in the template which is immediately reflected in all pages using this template.

But it’s definitely worth it.

I thought my site was simple, but it wasn’t. Or at least not simple enough.

Lesson learned.

Pretended Intentionality

2021-10-21

Pretended Intentionality

2021-10-21

I have recently become aware of an interesting – and somewhat concerning – behavior of mine in relation to my phone: In those spare moments when I am waiting for something, for instance, and the inevitable compulsion to check my phone arises, I often do manage to resist that urge. But after that first little victory over myself, something interesting happens: My mind, unable to accept that it is denied the diversion it so much craves, is trying to come up with suggestions for things that would be worth doing with my phone while waiting:¹

What was it again that makes Ridge A such a special place? Now would be a good time to head over to Wikipedia and check it out – after all, there is not much else you can do right now anyway!

Which city in the world has the longest subway system, actually? Well, why not figure it out quickly?

Let’s check openbsd.org to find out whether the new OpenBSD release is already available.

My mind knows that I am trying to control myself in order not to compusively check my phone for no obvious reason whatsoever. And therefore, recognizing that just letting things run will not suffice this time, it becomes creative: Knowing that I am trying hard to act intentionally instead of compulsively and reflexive, it makes me believe that I do in fact act intentionally by rationalizing using my phone.

And thus my mind gets hold of me. It’s the monkey mind at work. But just like a real monkey, it is not just jumping around like crazy; it is also very clever and inventive.

What is so perfidious about it is that my mind is tricking me into the very behavior I am trying to avoid by convincing me that I am in fact avoiding it. Yet, this is all just another, albeit clever, strategy of my mind to run away from the slightest sign of boredom and instead indulge in distractions; that everlasting endeavor of the mind of not having to cope with the truly important things in life – or, at the least, of not having to sit alone in a quiet empty room.

The good thing is: Once you become aware of something you want to change, it becomes possible to actually change it.

I am mostly using the terms me and my mind here to refer to the conscious and subconscious parts of myself, respectively. ↩

Installation and Setup of the RainLoop Webmail Client on OpenBSD

2021-12-22

Installation and Setup of the RainLoop Webmail Client on OpenBSD

2021-12-22

Rainloop is a modern, simple and rather lightweight webmail client. This article describes its installation and setup on a local OpenBSD machine and the configuration necessary for accessing a Posteo e-mail account.

Tested with OpenBSD 6.9, PHP 8.0 and RainLoop 1.16.0.

Prerequisites

On a default OpenBSD installation, only a few things are required in order to get RainLoop set up and running:

Web server. Since we are on OpenBSD, we will be using httpd(8).
PHP. In addition to the extensions contained in the base installation, only PHP-cURL is required, and optionally PHP-PDO for contacts.

No database is required for the core functionality; it is only needed for storing contacts, which is optional.

Installation and Setup

httpd

Create an entry in /etc/httpd.conf for a HTTP server listening on localhost:8080 (of course, any other port can be specified):

server "default" {
  listen on "127.0.0.1" port 8080
  log {
    access "default-access.log"
    error "default-error.log"
  }
  root "/rainloop"
  directory index index.php
  location "/data/*" { block }
  location "*.php" {
    fastcgi socket "/run/php-fpm.sock"
  }
}

Here, it is assumed that RainLoop will be installed in /var/www/rainloop, which therefore needs to be set as the document root for the server. Also, web access to the data subdirectory must be blocked.

Start httpd(8) unless it is already running:

$ doas rcctl enable httpd
$ doas rcctl start httpd

Otherwise, simply restart it:

$ doas rcctl restart httpd

PHP

Install php(1) unless already done:

$ doas pkg_add php

Start the PHP FastCGI Process Manager (PHP-FPM):

$ doas rcctl enable php80_fpm
$ doas rcctl start php80_fpm

Install the PHP-cURL extension and make it known to PHP:

$ doas pkg_add php-curl
$ doas ln -sf /etc/php-8.0.sample/curl.ini /etc/php-8.0/

Optionally, install the corresponding PHP-PDO extension for the database to be used (in this case SQLite; other options are MySQL and PostgreSQL) and make it known to PHP:

$ doas pkg_add php-pdo_sqlite
$ doas ln -sf /etc/php-8.0.sample/pdo_sqlite.ini /etc/php-8.0/

RainLoop

Create a directory for RainLoop under /var/www:

$ doas mkdir /var/www/rainloop

Get the latest version of the RainLoop Community edition and unzip it in /var/www/rainloop:

$ doas mkdir /var/www/rainloop
$ cd /var/www/rainloop
$ doas ftp https://www.rainloop.net/repository/webmail/rainloop-community-latest.zip
$ doas unzip rainloop-community-latest.zip
$ doas rm rainloop-community-latest.zip

Set the owner of the data subdirectory to www:

$ doas chown -R www data

Finally, copy /etc/resolv.conf to /var/www (otherwise, the domain names of the mail servers may not get resolved to their corresponding IP addresses):

$ mkdir -p /var/www/etc
$ doas cp /etc/resolv.conf /var/www/etc/resolv.conf

RainLoop can then be accessed via the URL localhost:8080, and it can be configured in the admin panel which can be accessed via localhost:8080?admin.

Accessing a Posteo E-Mail Account

Access to a Posteo e-mail account can be set up by creating the file /var/www/rainloop/data/_data_/_default_/domains/posteo.de.ini with the following contents:

imap_host = "posteo.de"
imap_port = 993
imap_secure = "SSL"
imap_short_login = Off
sieve_use = Off
sieve_allow_raw = Off
sieve_host = ""
sieve_port = 4190
sieve_secure = "None"
smtp_host = "posteo.de"
smtp_port = 587
smtp_secure = "TLS"
smtp_short_login = Off
smtp_auth = On
smtp_php_mail = Off

Alternatively, the account can be set up via the admin panel.

References

Taking Screenshots on OpenBSD

2022-01-30

Taking Screenshots on OpenBSD

2022-01-30

I rarely need to take screenshots, but occasionally it is convenient to be able to do so. The method described here uses maim, cwm(1) and ksh(1). I use it on OpenBSD, but it should work in a very similar way on all Unix-like operating systems.

Here is how it works:

Preparation

Install maim:

$ doas pkg_add maim

Create a script with the following content and save it to ~/bin/screenshot (assuming ~/bin is in the user’s PATH):

#!/bin/sh

maim -s | xclip -selection clipboard -t image/png

All this script does is invoking maim to prompt the user to select the region of the screen he wants to take a screenshot of, upon which maim will create a PNG image of the region, which is then copied to the clipboard.

Make the script executable:

$ cd ~/bin
$ chmod u+x screenshot

Define a keybinding in ~/.cwmrc for invoking screenshot via the key combination <Alt> + s (of course, any other combination works as well):

bind-key M-s "bin/screenshot"

Define an alias in ~/.kshrc for pasting the image from the clipboard to a file:

alias clip2file='xclip -selection clipboard -o >'

That’s it.

Taking a Screenshot

Then, to take a screenshot, do the following:

Press <Alt> + s.
Select the region of the screen you want to take a screenshot of.
Go to a terminal and type:
```
$ clip2file <file>.png
```

The resulting screenshot will be saved to <file>.png.

Derek Sivers: “How to Live”

2023-03-05

Derek Sivers: “How to Live”

2023-03-05

To state it upfront: How to Live is a book which can hardly be overrated. It is full of wisdom, packed even more densely with insights than Dereks’ previous writings.

The title of the book asks one of the most important questions of life – maybe the single most important one –, and it implies that the book sets out to answer this question.

Instead of answering the titles’ question, however, the book presents us with twenty-one ways how to live. Each of the 21 short chapters explains how to live a life according to a certain guiding principle. It describes how to live in complete accordance with that principle, to adhere to it with the utmost consequence.

But: All of the 21 ways to live are completely incompatible with each other, due to their conflicting guiding principles.

So does this book answer the question posed in its title? No. Instead, it presents possibilities. Every single chapter is convincing and persuading, yet every one is completely different than any other.

To me, the core statement of this book is that there are no definite answers, at least not to the really important questions of life. We humans yearn for answers, for recipes, for certainty – yet at some point, everybody has to face the fact that there are no simple, universal answers to the truly important questions. Life is contradictory, often messy, rarely proceeding along a straight line. And, most important: Each life is absolutely individual, and everyone has to find his own answers.

Just as remarkable as the books’ content is its form. It is incredibly dense. Derek somehow manages to picture the different ways to live in often not more than three or four pages. Most sentences are very short, often fitting on a single line, and new sentences always start on the next line. His writing is never pleasing, but always sharp and to the point, and with “How to Live” he has perfected his style. To me, it is supremely elegant.

Two quotes come to my mind when thinking of “How to Live”:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” by Antoine de Saint-Exupéry. It seems to me that this was Dereks’ personal guiding principle in writing this book.

The second one is by Michelangelo: “The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.” I can imagine how Derek spent hours and hours chiseling away the superfluous words, finally achieving something which comes very close to the perfection as it is defined in the quote by Antoine de Saint-Exupéry above.

Making a point using many words is easy; making a point using very few words is exceedingly difficult. Derek has succeeded in every aspect.

If you have not read the book yet, buy it and read it, immediately. Then, after some time, read it again, and again.

Derek Sivers: “Useful Not True”

2025-07-06

Derek Sivers: “Useful Not True”

2025-07-06

Useful Not True is another gem by Derek Sivers. Whenever he publishes a new book, I order it immediately, no matter what it is about. I know from experience that everything he writes is packed with wisdom and insights I don’t want to miss.

Let me start with the form of the book (I am referring to its physical version here): It is short, as Derek’s books usually are. Most chapters are one or two pages at most, very few are longer. The font size is pretty large, as well as the distance between lines, and the lines are rather narrow, which makes the reading a very pleasant experience. This is in contrast to many other books which look as if they were laid out with the goal to pack as many words as possible on each page. With Derek’s books, it is the exact opposite, with respect to both form and content: They look as if the goal was to use as few words as possible (and it was!). They are a perfect example for James Altuchers’ maxim “To increase the value of ~~your~~ words, make them as few ~~as possible~~.”

The content of the book perfectly matches its form: It is distilled to the bare minimum of what is necessary to convey its point. Nothing is superfluous; every word serves a purpose. One could certainly easily inflate the books’ content to 1000 pages, but it would not be possible to reduce it to fewer pages without losing content.

Useful Not True is a book about perspective. Everything is relative; nothing is absolute. There is no “right” or “wrong”, just “useful” or “useless”. While reading it, so many associations popped up in my mind:

To Zen Buddhism with its belief that everything is made up by the mind alone and its seeking for looking at things as how they are, without making up things about them in our mind.

To phenomenology and its concept of epoché (and similar concepts in Stoicism and other philosophies), a method for refraining from subjective judgements of things or situations.

And even to physics and mathematics, in different aspects: In gauge theories, there are intrinsic unphysical degrees of freedom. By fixing the gauge, those unphysical degrees of freedom can be removed. And this can be done in different ways, depending on what is most useful in the respective situation.

Also, physical theories are formulated as models which describe (physical) reality. They never do it perfectly, though, because they cannot capture every aspect of reality. And yet, good models are extremely useful (and a good model is not necessarily one that describes reality most accurately; it may be perfectly sufficient to describe a very particular aspect of reality with a certain coarseness if it still captures the relevant physical mechanisms). As George E. P. Box put it: “Essentially, all models are wrong, but some are useful.”

The importance of the book lies in the fact that, while its statement seems perfectly plausible, we very often tend to ignore it. Ask two people standing opposite each other where the river is. The one says: “On the left.” The other says: “On the right.” Who is right? It is remarkable how firm our belief is that there is “right” and “wrong”, while it is so obvious that this is usually not true, if we just looked at things as they are. While the consequences may be trivial as in the example above, they can be arbitrarily grave in other situations.

So, on the one hand, recognizing there are no absolutes can prevent us from making mistakes in judging situations. But there is another aspect, which is hinted at in the title of the book: We can turn this realization to our advantage. You can face a wall, or you can turn around and look at a serene beach. Both perspectives are “right” or valid. Why not choose the one you like better? There lies power in not being confronted with the one “true” perspective, but instead being able to choose ones preferred perspective, and this power can be harnessed – provided we know that we can simply turn around.

I will end with my usual recommendation of Derek’s books: Buy it, read it, and digest its content as fully as possible! It is worth every word.

Relay Mail to a Remote SMTP Server With `smtpd`

2022-03-27

Relay Mail to a Remote SMTP Server With `smtpd`

2022-03-27

Configure smtpd(8) to relay outgoing mail to a remote SMTP server as follows:

Create the file /etc/mail/secrets:

$ doas touch /etc/mail/secrets
$ doas chmod 640 /etc/mail/secrets
$ doas chown root:_smtpd /etc/mail/secrets
$ doas echo "label username:password" > /etc/mail/secrets

username and password are the credentials for accessing the remote SMTP server, and label is an identifier for the username-password combination. It can be chosen arbitrarily and is used in smtpd.conf (see below). Since the credentials are stored in plain text, restrictive permissions are set for the secrets file.

Replace the default content of /etc/mail/smtpd.conf with the following:

table aliases file:/etc/mail/aliases
table secrets file:/etc/mail/secrets

listen on lo0

action "local" mbox alias <aliases>
action "relay" relay host smtp+tls://label@smtp-server:port auth <secrets>

match for local action "local"
match for any action "relay"

label is the corresponding label from the secrets file, smtp-server is the URL of the remote SMTP server, and port is the mail submission port (default: 587).

Verify that the configuration is syntactically correct:

$ doas smtpd -n

smtpd will answer with:

configuration OK

Restart smtpd:

$ doas rcctl restart smtpd

smtpd will answer with:

smtpd(ok)
smtpd(ok)

Test the configuration by sending an e-mail using mail(1):

$ echo "This is a test" | mail -s "Test" mail@example.com

References

smtpd.conf(5)
Forward outgoing mail to a remote SMTP server by Roman Zolotarev.

Multiple-Click Selections in xterm

2022-02-12

Multiple-Click Selections in xterm

2022-02-12

It is possible to configure in detail which portion of the screen – a word, a line, etc. – is selected in xterm(1) on rapid successive mouse clicks.

What is a Word in xterm, After All?

In xterm, words can be selected by double-clicking on any character in the respective word. This will highlight the word, and it is then in the primary selection of the X Window System and can be pasted elsewhere.

Characters are grouped into character classes. Words are defined in xterm as strings of characters belonging to the same character class. Therefore, what xterm interprets as a word depends on the mapping of characters to character classes.

In the default mapping, alphanumeric characters and the underscore belong to one character class, space and tab belong to another character class, and all other characters have their own character class. This definition works well when dealing mostly with prosaic texts, since it more or less corresponds to the usual definition of a word (i.e. certain characters separated by whitespace). In other cases, it is less convenient though. For instance, it is not possible to select a path consisting of several directories by double-clicking on it, since directories are separated by a slash, which belongs to a different character class than alphanumeric characters and the underscore.

Interestingly, the mapping can be changed via a certain xterm resource called charClass. Its value is a list of key-value pairs, where the key is either a single character code or a range of character codes, and the value is a character class. A given key-value pair then defines that the character(s) specified by the key belong to the character class specified by the value.

Character classes are identified by numbers (which in turn correspond to the character code of a representative of that character class). The default mapping of characters to character classes is given in the respective section of the manpage. In the default mapping, alphanumeric characters and the underscore belong to character class 48 (the character code of the character 0), and space and tab belong to character class 32 (the character class of space).

Therefore, in order to add e.g. the characters ! (character code 33) and : (character code 58) to character class 48, add the following line to ~/.Xresources:

xterm*charClass: 33:48,58:48

To add all “regular” characters to character class 48, add the following line to ~/.Xresources:

xterm*charClass: 33-126:48

Activate the change:

$ xrdb -merge ~/.Xresources

xterm Knows More Than Just Words

Words are just one kind of character grouping in xterm. The full list is:

word: As defined above.
line: The entire line to which the character under the pointer belongs to.
group: Basically the paragraph the character under the pointer belongs to, i.e. all lines above and below up to the next blank line. Does not extend outside the current page.
page: All visible lines on the current page.
all: All lines, including i.e. saved lines.

Even that is not all there is, though. On top of that, it is even possible to define custom groupings via regular expressions (basically, all other predefined groupings are just shortcuts; they could just as well be defined via a corresponding regular expression). Also, there is the pseudo-grouping none which specifies that no selection should occur in the respective case.

So it is possible to specify in a very fine-grained way what will be in the primary selection when double-clicking on some character. But it can be specified just as well what happens when clicking multiple (i.e. more than two) times in rapid succession. This is useful since one may be interested in selecting different character groupings depending on the respective case. For instance, in the default configuration, triple-clicking usually selects the entire line. Which character grouping is selected when clicking 2, 3, 4 and 5 times in rapid succession is specified by assigning one of the character groupings defined above to the xterm resources on2Clicks, on3Clicks, on4Clicks and on5Clicks, respectively.

As an example, in order to specify that double-clicking should select words defined as a string consisting of alphanumeric characters, the underscore, the exclamation mark and the colon, that triple-clicking should select words defined as a string consisting of all regular characters except whitespace (defined via a corresponding regular expression), and that clicking four times in rapid succession should select the entire line, add the following lines to ~/.Xresources:

xterm*charClass: 33:48,58:48
xterm*on2Clicks: word
xterm*on3Clicks: regex [^[:space:]]+
xterm*on4Clicks: line

Even when using the mouse sparingly, it is very convenient to be able to specify what gets selected on multiple clicks in xterm, and it certainly does save some time.

Quake Discoveries

2026-03-14

Quake Discoveries

2026-03-14

Here is a question I am sometimes pondering: Can there be discoveries which completely shatter our worldview and our understanding of ourselves and the universe we live in? For lack of a better term, I will call such discoveries “quake discoveries” in the following.¹

To be clear: I am not talking about discoveries which simply question or change our worldview. I am talking about experiences which shatter it altogether, which break it apart irreparably and leave behind nothing but debris.

Take, for instance, the discovery of the theory of relativity, or of quantum theory: These were certainly discoveries which adjusted our worldview. Suddenly, it was clear that the universe was completely different than we thought – at least in certain aspects. Many people were probably confused, maybe even aghast when they first heard about these theories. Maybe they did not want to believe them and were thinking that they could not be true. Yet, most likely, this is what happend to most people after having digested the initial shock: At the end of the day, they went to bed. The next day, they got up and went to work. And that was it.²

These are not the kinds of discoveries I am talking about here. I am talking about discoveries which will not allow one to just get up the next morning and go to work. I am talking about discoveries which throw us out of our world, of our universe; discoveries which render it impossible to get up as the same person as the day before. Discoveries which, from one moment to another, change everything. Discoveries after which nothing will ever be as it was.

I am talking about discoveries which mankind has never made before, never in its entire history. Sure, most people were shocked and upset when they learned that the sun does not revolve around the earth, that the earth is not the center of the universe. But did that stop them from meeting friends, playing games, chatting with each other? Most likely not. Shortly after this discovery, they went on with their lives as usual.³

So, I am talking about discoveries of a whole different kind. But what could such discoveries look like? I do not know; after all, there are no examples to be found in history. What I usually imagine is something like the discovery in the film “The Matrix” that what people believed to be their real life was actually nothing but a simulation. I guess that would be a discovery which would not allow you to simply get up and go to work the next day. But then, who knows?

Possible future discoveries with respect to the nature of time or the mind might also be candidates for discoveries of this kind. Then again, discoveries cannot be predicted, and their kind or nature can be predicted even less.

The point is this: So far, all discoveries mankind has ever made in its history have at most shaken our worldview, leaving us back confused, but still within our universe. They may have thrown us on the floor, but they left us in our familiar environment. Our perspective has changed, but only momentarily.

Quake discoveries, on the other hand, would kick us out of our universe and destroy every bridge which might enable us to ever return to it. It would throw us into another universe altogether, into a distant and foreign place. It would leave us completely disoriented.

Will we ever make such discoveries? Is that even possible, given that our direct experience and perception of the world can probably never be changed by any discovery whatsoever? After all, even if we found out that we live in a gigantic simulation, we would still feel the warmth of the sun on our skin; we would still get hungry and tired, and we would still have wishes and desires. And even if we knew that we live in a gigantic simulation, it would still feel like the real world. So, can mere knowledge ever have these effects I am talking about?

I do not know the answer, but I find this a fascinating question.

The term “disruptive discoveries” would probably sound more serious, but does not really seem appropriate for what I am talking about here. ↩
Of course, many people – in particular those dealing professionally with these theories – continued to deal with them and their consequences for a long time and in many cases even fought hard fights within themselves before they were able to accept them. I doubt, however, that any of those people perceived these discoveries as existential threats to their worldviews. ↩
With the exception of those who felt threatened by those discoveries and tried to forcefully hide or miscredit them, of course. ↩

Vim and PKM

2026-04-30

Vim and PKM

2026-04-30

First things first: It is a pleasure to once again participate in a Vim Carnival, created and hosted by the fabulous Hyde.

Though the topic of the Vim Carnival - April 2026 is: “How do you use Neovim/Vim to build your knowledge management?”, let me state upfront: This article is going to be more about personal knowledge management (PKM) than about Vim. After all, Vim is “just” an editor, which is per se agnostic to what it is employed for – be it writing todo lists, emails, books, doing PKM or whatever. So honestly, I am somewhat stretching the idea of the Vim Carnival with this contribution. For the short (and maybe a bit disappointing) answer to the above prompt, you can jump directly to the section And what about Vim? at the very end.

A short note regarding terminology: In this article I will use “Vim” as a placeholder for vi-like editors in general. In particular, it includes both Vim and Neovim, but even plain vi¹.

A short preface

Actually, this Vim carnival is a welcome prompt for a subject I intended to write about since a long time, but never came around to doing: That is, how I do PKM.

I won’t delve into the “theory” of PKM in any detail here. There is a lot to say about PKM, and a lot has already been said about it in the past and will be said about it in the future (and I am no expert at all in this matter). The risk in writing an article like this one is to completely get lost in the many aspects and facets of PKM. So I deliberately try not to let that happen and will focus on very few aspects – mostly on the technical implementation of my PKM system – in the hope of not ending up with a complete mess of an article.

So, here we go…

PKM on a computer

I have long dabbled with the challenge of PKM (long before I even knew a term existed for it and a large and active community has developed around it) – that is the challenge of how to manage knowledge (i.e. not just to store it, but to actively use it and engange with it in a meaningful way): Be it storing ideas for later reference, short notes, how-tos, trivia, inspirational quotes or whatever one considers worth remembering or needs to remember.

While implementing an analog PKM system (i.e. a system not relying on a computer) is very well possible – after all, people have been doing it for hundreds if not thousands of years –, the advent of computers has certainly opened up new possibilites, like organizing documents in different fashions, searching in them and filtering them according to certain criteria. I will not discuss the advantages and disadvantages of analog and digital forms of PKM here and instead, without further explanation, focus on digital PKM systems from here on.²

The question then is: How to implement a PKM system on a computer? While dedicated tools – from simple to highly sophisticated and complex – abound, I have always had a certain aversion to them. I guess it stems from the fact that I have always thought that there must be a really simple way to implement such a system, a way that is efficient and so robust that it can stand the test of time (and the coming and going of software tools…).

This does not mean that there are no good tools around for implementing a PKM system. Even when taking into account some of my basic requirements, like

notes must be stored as plain text,
the tool must be open source (to prevent vendor lock-in, among others),
it should be simple and not suffer from feature creep,

there is still a respectable number of tools which satisfy these. Yet, I have never come to really like them. Even Obsidian, a tool which has many dedicated fans and which I really appreciate, is not for me, mostly for two reasons (which are directly connected to the requirements above): It is too complex for my taste and offers way more features than I would ever need, and – no matter how successful and widely used it is today –, it will most likely be gone someday.³

Therefore, I have always preferred to build my own PKM systems, tailored to my specific needs (which sounds more grandiose than it actually is; hold on).

The simplest PKM system

But first, let us take a step back. The simplest system for storing notes – the one most people have used decades ago, and in particular before the advent of graphical user interfaces – is storing them in plain text files, one per note, in some directory (or directory structure). There is basically just one ingredient necessary for setting up such a system on a computer (apart from rather obvious things like a file system): A text editor for creating and editing notes.

With nothing more than this, working with the system is somewhat limited. But as soon as basic tools available (and usually preinstalled) on essentially all Unix-like operating systems are taken into account, we already gain quite a bit:

A pager like less lets us view notes.
grep lets us search notes.
ln lets us link notes (for creating aliases, for instance).

and so on.

And honestly, I still feel that not much more is needed for implementing a PKM system on a computer. While I tend to spend much time thinking about how to best implement things, sooner or later I usually feel myself drawn to very simple solutions with few dependencies. Here, as in many other cases, the danger lies in spending so much time setting up and administrating the system that one does not really use it at all.

There are basically just two things I would really miss with a pure plain text approach like this one: The ability to tag and to link notes. While tagging would be possible by, for instance, prepending tags with a certain prefix like “#” and then using grep to find notes containing them, that would be a little cumbersome. But I have not been able to find a good solution for linking notes (in particular linking from a specific point in a note) with this approach.

Here HTML comes to the rescue – or rather leightweight markup languages like Markdown or AsciiDoc which translate to HTML.

A little bit of (personal) history

Before explaining the system I am currently using, however, let me briefly mention three of the many self-built systems I have used over the years. I have chosen these because of the different ideas and concepts they were based on.

A self-written simple static site generator where notes were written in AsciiDoc and included front-matter for metadata like tags etc. (actually, it was a derivate of a static site generator I built for my website). Since the output format was HTML, linking between notes was easy. Since the output was static, though, it was only possible to filter for single tags; dynamical filtering was simply not possible. This may be fine for a personal website, for instance, but it is definitely a drawback for a PKM system.
A pure plain-text system where notes were stored as plain-text files without any structured markup (like Markdown or AsciiDoc) at all. Tags were implemented via symbolic links to (empty) directories named like the given tag, and links between notes were implemented via symbolic links between these notes (I got the idea of using symbolic links for implementing tags by the great article “The Case Against Everything Buckets” by Alex Payne, which unfortunately is no longer available online to my knowledge). What I really liked about this system was that it depended only on tools which are already available on any Unix-like system (an editor, a pager, symbolic linking etc.). All the linking was somewhat cumbersome, however, and in particular error-prone. Therefore, I wrote a simple shell script which provided convenience functions for viewing, editing, tagging and linking of notes (and in particular for carrying out all the linking). A major disadvantage of this system was that linking was only possible on the level of the notes themselves (i.e. you could link note A to note B, but you could not link from a specific point in note A to note B).
Another pure plain-text system with unstructured plain-text notes where tags of notes, links between notes and other metadata was stored in a JSON file (thereby separating metadata of notes from the notes themselves). This was meant to solve the problem that I did not want to have metadata directly in my notes, as well as the problem of having to create all those symbolic links in the system mentioned above. A Ruby script provided convenience functions similar to the ones mentioned above (and in particular for managing the JSON file, which would have been rather impractical and error-prone to do manually). In addition, notes were stored in a Git repository, and the script automatically committed changes to the repository when creating or editing notes. The main disadvantage of this system probably was that, while it was designed with the idea in mind that everything should be doable without special tools like my Ruby script, editing the JSON file and committing to the Git repository was cumbersome and error-prone and could easily be forgotten when done manually. So, while having a separate file for storing metadata information for my notes was more robust than employing symbolic links, I felt that the problems were only shifted to different areas.

While all these systems worked and did what they were meant to do, I was never really satisfied with them. The main problem was that I never really worked with them. They were based on certain ideas and principles I had in mind, but it turned out that the theory of conceiving them and the practice of using them diverged.

My current system

The system I am currently using is the one I am most happy with so far. It does not solve all problems, but it is the one which currently works best for me.

The main design goals of my system are (and have pretty much always been):

It should be usable as a pure plain-text system without any kind of dedicated software processing the notes or operating on them (i.e. using only standard tools like text editor, pager, grep etc.).⁴
It should be simple and have very few dependencies.
It should be platform-independent and future-proof.

All my notes are stored in a single directory called, well, notes (this is not different from practically all the other systems I have used in the past, like the ones mentioned above). Notes are Markdown-formatted plain text files.⁵ There is (almost) no metadata contained in my notes. In particular, there is no front-matter (i.e. structured metadata) at the top of a note. While front-matter makes it easy to parse metadata programmatically, it somewhat clutters the notes and is not so easy to parse without specific tools (which contradicts the first of my design goals).

There are only two special syntactical constructs which extend Markdown and have a special interpretation in my system:

Words prefixed with # at the beginning of a note are interpreted as tags.
Strings matching the pattern [[<note>]] or [[<title>|<note>]] are interpreted as internal links, i.e. links to other notes.

The system is perfectly usable with nothing more than this (note in particular that the syntax for the two special constructs for tags and internal links mentioned above is so unobtrusive yet self-explanatory that they would even work without rendering the notes). In particular, it satisfies my first design goal; for instance, some basic operations could be done like this:

Viewing a note: less <note>
Editing a note: vim <note>
Searching for a given string in all notes: grep <string> *
Filtering notes on given tags: grep -l -e "#<tag1>" -e "#<tag2>"
Finding all notes which link to a given note: grep -l "\[\[<note>\]\]" *
Finding all notes which are linked to from a given note: grep -o "\[\[.*\]\]" <note>

Note the small number of tools needed to achieve these operations.

However, to be able to efficiently use tags and links (which are integral ingredients in a PKM system), it is convenient render notes as HTML and view them in a browser. In my system, the preprocessing and rendering of the notes is facilitated by a small Ruby program I wrote.⁶ Since the notes are written in Markdown, it is easy to convert them to HTML by employing standard libraries or APIs available in most programming languages. The tool provides a simple web application employing the Sinatra web framework. This in particular facilitates serving content dynamically (in contrast to the static site generator I used as a PKM system in the past; see above). This makes it possible, for instance, to filter for several tags, since the code determines the matching notes dynamially before they are getting rendered and served.

While the notes are mostly simply translated from Markdown to HTML, marks and links are preprocessed as follows:

Tags are extracted from the note so that they can be laid out separately in the rendered note (to make them appear below the note title instead of above it, for instance, or to make them link to a page which lists all other notes with that tag).
Internal links are converted to a link to the given note, which is displayed with the respective title if given. This is a Wiki-style shortcut for internal links (i.e. links to other notes).

A note can then be reached via the path /note/<note> and viewed in the browser by entering the corresponding URL (i.e. the host – localhost if run locally – plus this path). This is what a rendered note might look like in the browser.

There is also an index page listing all the notes available (and also one for listing all the tags defined), so it is easy to directly navigate to them instead of having to enter the URL manually.

Note that, according to my second design goal above, things should be simple. Therefore, there is basically no explicit user interface for doing things like filtering (after all, I am the only one using the system…). Instead, the filtering can be done by appending query parameters to the corresponding path. For instance, the path for filtering notes on tags “tag1” and “tag2” would be: /?tag=tag1,tag2

In addition, there are a few endpoints for doing certain consistency checks, like whether there exist links to non-existing notes, which is then reported so that it can be fixed.

Note that it is not possible to create, modify or delete notes in any way using the web interface (it works in a purely functional way, one might say). This is a deliberate choice: Deleting and renaming can easily be done using rm and mv on the command line, and editing is exclusively done using my editor of choice – that is, of course, Vim (so, I have finally turned things around and arrived at the actual subject of this article - yay!).

So much about the technical implementation of the system. Regarding its organization: It is more or less based on the Zettelkasten approach⁷, but I will not go into any detail about it here. I am trying to write notes which are atomic, i.e. which entail a single idea or concept, and to link them to create semantic connections to similar of related ideas or concepts (though I often fail at doing this in a good fashion, I think). As mentioned in the beginning, though, this is not the focus of this article, so I will just refer to the many good resources about the organizational aspects of PKM in general, and the Zettelkasten method in particular, available out there.

And what about Vim?

So, I have written a lot already, but rarely mentioned Vim at all. Considering that this is a contribution to a Vim Carnival, the question “Where does Vim come into play?” imposes itself.

The – somewhat trivial – answer to this question is: Where it always comes into play when I work with plain text files. I use it, obviously, to edit my notes – just as I use it to edit any other kind of text file.

So, I hope Hyde will forgive me for somewhat abusing this Vim Carnival for my ramblings about PKM. Let me close this article, however, by emphasizing that, while there is nothing special in my using of Vim for PKM, it does play an extremely important role in it. It’s a simple syllogism:

I edit plain text files in Vim.
My notes are plain text files.
Therefore, I edit my notes in Vim.

I want to be able to edit text files as smoothly and efficiently as possible: That is why I use Vim – for PKM and everything else that comes as plain text.

I know it sounds somewhat strange to call plain vi “Vim”. Then again, this is an article for a Vim Carnival, so what… ↩
Examples of analog PKM systems are commonplace books, which have been around for centuries, and the Zettelkasten method, probably most famously employed by Niklas Luhmann, which is often used in an analog way (though it can also be implemented on a computer). ↩
I know: Since notes are stored in Markdown-formatted plain text, they can even be used if Obsidian (or whatever other tool) is gone someday. Yet, I prefer to depend as little as possible on external software. It is a rather mild case of vendor lock-in – much less so than with many other applications –, but I like to not only own my data, but also the software which operates on it (which, of course, is only possible in rather few cases). ↩
This basically means that my system would fall back to the basic plain text approach I sketched earlier. My notes would still contain markup in the form of Markdown, but one of the nice properties of Markdown (even more so than with other markup languages like AsciiDoc) is that Markdown does not distract much from the text; it integrates rather seamlessly into it. So even if Markdown would cease to exist, along with every tool to generate HTML from it, it would still be viable as some kind of self-explanatory plain-text markup. ↩
In the past, I have mostly used AsciiDoc. I switched to Markdown because I do not need all the power of AsciiDoc, and the markup of Markdown is less intrusive than that of AsciiDoc (which is more intrusive precisely because it is more powerful), thereby making it even more readable. ↩
The tool can be found here: https://codeberg.org/thorstenzoeller/noted. Note, however, that it is not quite up-to-date; in particular, this version only works with AsciiDoc-formatted notes (not with Markdown-formatted notes). An updated version will (hopefully) be provided soon. ↩
Some good ressources for starters are:
And no, I actually do not like footnotes that much, even though it very much seems to be exactly so. I just usually fail not to extensively make use of them. Fortunately, you have now made it to the last footnote of this article… ↩

Thorsten Zöller - Articles

Running Anki inside Xephyr

Running Anki inside Xephyr

The Melancholy of the Day

The Melancholy of the Day

Michael W Lucas: “Ed Mastery”

Michael W Lucas: “Ed Mastery”

How I Use Vim

How I Use Vim

My History of Using Vim – A Personal Account

So, How Do I Actually Use Vim?

Further Reading

A Simple E-Mail Reminder System Based on cron and at

A Simple E-Mail Reminder System Based on cron and at

The Setup

Usage

Recurring reminders

Nonrecurring reminders

Caveats

My New Website

My New Website

Pretended Intentionality

Pretended Intentionality

Installation and Setup of the RainLoop Webmail Client on OpenBSD

Installation and Setup of the RainLoop Webmail Client on OpenBSD

Prerequisites

Installation and Setup

httpd

PHP

RainLoop

Accessing a Posteo E-Mail Account

References

Taking Screenshots on OpenBSD

Taking Screenshots on OpenBSD

Preparation

Taking a Screenshot

See Also

Derek Sivers: “How to Live”

Derek Sivers: “How to Live”

Derek Sivers: “Useful Not True”

Derek Sivers: “Useful Not True”

Relay Mail to a Remote SMTP Server With smtpd

Relay Mail to a Remote SMTP Server With smtpd

References

Multiple-Click Selections in xterm

Multiple-Click Selections in xterm

What is a Word in xterm, After All?

xterm Knows More Than Just Words

Quake Discoveries

Quake Discoveries

Vim and PKM

Vim and PKM

A short preface

PKM on a computer

The simplest PKM system

A little bit of (personal) history

My current system

And what about Vim?

Relay Mail to a Remote SMTP Server With `smtpd`

Relay Mail to a Remote SMTP Server With `smtpd`