Vim: Basic Text Navigation and Editing

Basic navigation ¶

I stated in a previous post that the main innovation of Vim is making the insertion of text secondary to navigation. Let’s put my money where my mouth is. The following assumes you are in normal mode.

It is useful to conceptualize a bit first. In MS Word text navigation is done mainly by 1) using the arrows, 2) mouse clicking, 3) mouse scrolling. Some expert Word users perhaps navigate between words and paragraphs by using Ctrl + arrow key. In (pure terminal) Vim, navigation has to be done without the mouse. Are we then only left with the arrow keys, or h j k l?

Getting rid of the mouse forces you to think about navigation on different levels. There is navigation within words. But also navigation between words within sentences, between sentences within paragraphs, between paragraphs within pages, and between pages/screens. I leave navigation between files aside for now. Only if you choose the appropriate level for your situation will text navigation in Vim be more efficient than for other editors. When starting out with Vim you will probably be a bit inefficient, but over time reviewing your behavior should result in good habits.

Within words: on the lowest level you navigate with the basic navigation keys h j k l. Do not use the arrows, since this requires you to move your hand away from the central keyboard position. To force yourself to do this, and simultaneously make the arrow keys useful for something, consider mapping your arrow keys to resize windows.

Between words: If you are editing within a sentence and want to jump to particular word, you have some options. You will notice that most key commands are easy to remember based on what they do. If you want to jump towards the end of a word, press e. To instead go to the beginning, press b. So far so good. To jump to the beginning of the next word, press the w from “word”. In long sentences this can still feel a bit inefficient, but you do have some options:

1. Repeat your command. E.g. to jump three words forwards, type 3w.

2. Quickly find and jump to a character. If your cursor is on “Repeat” in the previous sentence, and you want to jump to the middle of the sentence, you could find ‘w’ with fw to end up at the beginning of the word “words”. If you want to end up before that word, jump “to” or “till” it with the t command.

3. You can also quickly search and move to a word in a sentence if more convenient, for example when a sentence is long. Quickly typing /wo and pressing enter is enough to jump to “words”. For backward search, use ? instead.

If you want to jump to the beginning of the line, press 0. Surprising? This one is less obvious, but $ moves towards the end of the line.

Between paragraphs: Use { and } to jump back and forth between whole paragraphs.

Between pages/screens: ^f and ^b goes forward and back a page. Capitalizing instead makes you jump a whole screen: ^F and ^B. (Note that ‘^’ here indicates the CTLR button).

Quick and dirty mode switching ¶

After navigation, you most likely want to enter Insert mode. Vim offers commands for striking two birds with one stone; the birds being navigation and switching to insert mode. These are the basic commands that I really miss the most when I have to write in something else than Vim.

When writing you often pause to review your last sentence and fix some small error. Your cursor is in the middle of your last sentence, but now you want to continue writing on a new line.

I suspect something like this: 1) you go to the end of the sentence, either by pressing ‘End’ or by clicking on it with your mouse (in the latter case you have to take your hand of the keyboard). 2) You click enter to create a new line. 3) You can now start typing. Ok, that’s not too bad. But Vim does all of this with the command o, that opens a new line and leaves your cursor at its start. It doesn’t matter if you are in the middle of the previous sentence. If your last sentence also happens to be the last sentence of the file (e.g. you are writing a first draft) you can quickly pick up your work by jumping to the end of the file with G.

But Vim really does better in the scenario where you want to write a sentence before the currently selected sentence. In Word you would do: 1) move to beginning of the current line, 2) press enter, 3) go up a line, 4) you can now start typing. Vim still does all of this in a single keystroke. This does maybe not seem that impressive, but you would be surprised how often you will find yourself doing the previous if you pay attention to it. The capitalization of a command usually does a similar task slightly different. In this case O (so the capital o) does all of the described steps at once.

The same holds for i and I. i puts you insert mode, but I puts you in insert mode at the beginning of the sentence. Even more handy are a and A. a puts you in insert mode after the cursor, i.e. allows you to append text. So if you quickly want to append something to a word, you type ea to append after the end of the word. But often you want to append something at the end of the line. No problemo: A jumps towards the end of the line and leaves you in insert mode so you can immediately start typing. Notice that again there is some logic here that helps you remember this. Just like I does a similar operation but then on the line level, A does a but then for a whole line. The A command is amazing. You can leave a sentence half-finished, correct a small error, and then continue where you paused with a single keystroke.

Mastering the Grammar: Combining navigation and operations. ¶

You can navigate, so what? Well, Vim has a grammar that allows you to combine navigational keys or “directions” with basic operations and text objects, like verbs combine with nouns and adverbs. The main importance of this is that once you understand the building blocks, you can combine them into sensible commands without the need to remember them explicitly. So again, even though learning Vim is daunting initially, it becomes easier when you study the underlying logic instead of haphazardly learning commands.

So what are Vim verbs? The most important ones are d for delete, y for yank (a.k.a. copy), c for change, and v for visual selection. And what are the Vim nouns? In the previous section I mentioned navigation on the level of words, sentences, and paragraphs. Well, guess what w, s and p stand for? Let’s start combining:

• dw: delete until the beginning of the next word.
• 3de: delete until the end of the word three times.
• d0: delete until the beginning of the sentence.
• y$: yank/copy until the end of the sentence.

But this language is still a bit limited. We can specify the basic commands, such as delete, a bit further with modifiers such as i (inside) or a (around) that specify the command relative to a text object. For example:

• ciw: change inside word; notice that normally w jumps to the next word, but now you do not want to change until the beginning of the next word, but instead want to change the word object inside which your cursor is placed.
• dis: delete inside sentence. Deletes the sentence object inside which your cursor is placed. N.B. dd is a shortcut that does the same.
• yip: yank everything inside the paragraph object we are currently in. No dragging and selecting: we just specify the logic and Vim does the work.

And search functions t, f, /, and ? are also navigational in nature, so why should they be treated any different?

• d/yolo: delete until the first match of the word “yolo”
• dtm: delete till the character “m” (so not including “m”)

And even if you get creative, Vim often knows exactly what you mean.

• ci": change everything inside the quotation marks. Nothing to remember here, it just does what it says.
• da]: delete everything “around” the square brackets (so including brackets).

All of this combined opens a completely new perspective on text editing. The main downside however, is that when you start using Vim you will counteract the gained efficiency by delivering unrequested preaches about how much more efficient you are now that you use Vim.

In a follow up post I will focus on use cases less related to the act of writing itself and more to everything surrounding it.

Ten reasons for using Vim

Vim is a well-known (and infamous) text editor that is designed in such a handy way that some programmers even use it as their preferred IDE (Integrated Development Environment). That is quite remarkable if you think about it for a second: why would people replace proper software solely built for everything related to programming with a text editor? Apparently, Vim does text editing so well that people are willing to work around the limitations of using a “normal” text editor. That is a very interesting fact to me, because as a philosophy student I spent years editing texts. And I regret that I did not know about Vim earlier.

It feels like I lived in the stone age. By starting a second bachelor in Artificial Intelligence, a significant dose of programming entered my daily life. But, being a caveman, I initially followed all my programming courses without owning a laptop. After a fair bit of working on other people’s computers and emailing myself code (ouch…), I bought a second (or 3rd, 4th) hand Thinkpad T420 from a friend, with Antergos, an Arch Linux distro, installed on it. Over time I increasingly enjoyed customizing my workflow, and soon I saw myself disposing of my desktop environment and getting into the business of terminal multiplexing. But one painful remainder in this workflow optimization was my philosophy work: for text editing, MS Word on my Windows desktop was still my go-to program. In the meantime I was figuring out how to give shape to my remaining philosophy work next to a full-time study in AI. The activity of writing and text-editing was still secretly the thing I liked the most, but I didn’t get around to it anymore that often. So I thought: why not also have a programmer’s approach to text-editing as well? Exploring Vim was my way of mediating between my desire to write and my newfound daily life.

The main goal of this blog post is to convince you that Vim is not only useful for programmers and coding, but also for text editing of all sorts: from making notes, writing proza, to producing papers. It only requires familiarity with some basic concepts that might be unfamiliar to you, and a willingness to learn.

Vim’s basic philosophy ¶

Before I give you my ten reasons to use Vim, I want to explain how Vim effects what you could call a paradigm shift, and how this leads to confusion. The first experience that developers often have with Vim is that they enter it by accident, and then have no clue how to exit it. The popular platform Stack Overflow even wrote a blog post about how a million developers visited a popular thread on how to exit Vim. I was one of those people. After having used Vim for a while now, I would summarize the paradigm shift creating all this confusion as follows:

In Vim inserting text is of secondary importance to efficiently navigating your text

In your usual text editor, when you type a letter, the letter appears on the screen. As trivial as this may seem, this does not hold for Vim. Vim has different modes to manipulate a text, of which the “Insertion” mode is one among others, and not the default one. In order to make letters appear in your text, you first need to enter Insert mode. And here is the trouble: in order to exit Vim, you first need to exit this Insert mode, and enter Command mode to give the q(uit) command.

Inserting characters is a very straightforward operation where each keystroke corresponds to the inserting of a character on the screen. But by making this a secondary mode, Vim opens up the whole keyboard for highly efficient text navigation and manipulation. Think about this: when you write a document in MS Word, how much of your time do you actually spend typing, and how much time do you spend clicking, scrolling, dragging, and going through menu’s with your mouse? You’d be surprised.

But this different paradigm takes a while to get used to, and initially you wonder why something so simple as editing a text has to be so seemingly complex. But once you get comfortable with the basic logic behind Vim, you will never cease to be surprised how Vim can do things of which you did not even realize they were inefficient, more efficiently. I will try to give examples of that in a follow-up post.

My ten reasons for using Vim ¶

1) Improve efficiency

The main reason for using Vim is that it enables more efficient text editing due to its numerous commands. If you take for granted that Vim does this for a second, you might ask: but at what cost? Do I need to learn a hundred special commands? The answer is yes and no. Vim commands for text navigation and manipulation follow a basic grammar and are mnemonic. This means that if you learn some basic operations and a simple rule how to combine them, the amount of commands at your disposal grows exponentially. It is not hard to remember those basic operations, because they make sense.

2) Focus on the content (and think about the view later)

Vim and its ecosystem of plugins offers practically all the functionality you need, but without unnecessary bells and whistles. Traditional text editors such as MS Word have many menu’s, tabs and buttons. It usually takes me a while to find what I need exactly, but what annoys me more is that all these menu’s are distracting and take up a lot of screen space.

Vim instead helps you focus on what you want to get done without distraction. It provides you with a empty screen, and magic keybindings to perform text wizardry. Vanilla Vim only shows some very minimal and crucial information, for example in which mode you currently are. Okay, gVim (Vim’s graphical version) has a toolbar, but you can easily delete it completely.

Q: Let’s say you wrote something in Vim, but the only thing you now have is plain text. In MS Word everything immediately looks “right”. I type it, see it, and when I print it, it looks the same (usually) on paper. How do I get nice documents when writing in Vim?

A: You are used to a WYSIWYG-editor where content and view are presented on the same screen. But this is not the only way. Typesetting systems such as LaTeX require you to first define and structure your content, and then later magically compile your text into a really nice looking document. The only thing you have to do is indicate your preferences for how you want your document to look like, but you only have to do so once. After that you won’t have to spend a second thinking about it, so that you can focus on the content.

Unfortunately, LaTeX syntax can be quite cumbersome. If you do not require complex typesetting, a good option is writing in Markdown, which is an extremely easy format (you literally know how to work with it in 5 minutes), and it still has enough structure to create nice looking documents using everything HTML has to offer. This blog post is for example written in Markdown. When I deploy my website, the styling is applied automatically without me lifting a finger.

But you can also get the best of both worlds: the simplicity of Markdown, with the beauty of LaTeX. I personally write all my study notes in Markdown, and then use the amazing tool pandoc to create a nice looking pdf file with the good looks of LaTeX. Pandoc does this out of the box, but allows you to define your own LaTeX templates for converting markdown into pdf using a LaTeX engine. The other day I made my own template for compiling my study notes just the way I like it.

3) Universally readable file type without compatibility issues

Did you ever try opening a .docx document with a plain text editor? Everyone uses .docx because everyone uses MS Word. But .docx is only readable as intended through MS Word (let’s forget about OpenOffice for now). So everyone keeps using Word (and paying for it).

But then Microsoft decides that they are going to update their file format. You don’t really know why that would be better, but people around you buy PCs with Windows and Word pre-installed and suddenly they start sending you their documents in this new format. But your old version of MS Word does not support this version, so you have to buy the newest version (be part of the trend or get out).

None of this in Vim. Vim does old school plain text editing. Everyone can read and edit it with their program of choice, and you will not be bothered by compatibility issues.

And there are some more advantages to this:

4) Version control on your texts

Using plain text for your writing opens up the possibility to use adequate version control on your documents, for example using git. You can integrate git in Vim by using plugins, for example gitgutter, which indicates all changes in your text. On top of that, since you can run shell commands from within vim with the ! operator, you don’t even have to leave vim to run your git commands.

Programmers are already used to using tools like git, but why do people in the social sciences not exploit the amazing tools available nowadays? How most people do version control (if at all) is by simply having various different versions of the same document, and numbering them. Have fun keeping track of which of the numerous versions had all the correct changes in it!

Also, git is free. Which brings me to the next advantage of Vim.

5) Vim is completely free (okay, Charityware).

Vim is free, but comes installed with the friendly mention that if you want to give something back, you should consider donating money to a charity supporting orphan children in Uganda.

6) Vim is cross-platform

The files you write in Vim are readable by everyone, but on top of that vim (or gVim) is available for all major operating systems.

7) Highly extendable, fits whatever workflow

Vim is highly customizable to your needs, and there are numerous plugins available for all kinds of purposes. Do you want to use Vim as an IDE? Sure, you can setup autocompletion, automatic bracket closing, function and variable tags, file exploring, syntax checking and highlighting for your language of choice, etc. You are not a programmer but you like writing proza? Sure, install for example Goya and Limelight for a smooth and beautiful writing experience.

And one thing to not forget: you can run shell commands without leaving vim using the ! command. This means that whatever commands line tools you use, you can integrate vim in your usual workflow.

8) Vim (or at least vi) is ubiquitous

After learning Vim / vi keybindings, you will find that you can start up Vim on practically every Linux machine you will encounter. No hassle. Even if you need to do something on a remote machine terminal: vi will be there. Vi-bindings are so popular that you will see them appearing in other applications as well.

9) Vim is ergonomic

Vim allows you to do your work without ever having to move your hands away from the keyboard. I spent quite some time behind my computer, and not having my hand on the mouse continuously really helps me reduce stress on my right shoulder.

10) Have fun learning

Perhaps the best influence vim has on my workflow, is that whatever I do with Vim, it will indirectly be part of the bigger learning experience that Vim is. So Vim actually is a strong motivational factor for me. For example, taking notes is tedious, but now I see it as an opportunity to improve on my skills, and most importantly, enjoy the skills I have gathered so far.

The only downside is that sometimes you go down the rabbit hole looking for new Vim tricks.

I will write a follow-up post for some examples of how basic Vim use already helps me improve my efficiency.

Web scraping my own website in Python

Required:

• Python 3
• Python modules: requests, BeautifulSoup

A while back I suddenly felt the urge to do some quick programming after having spent the last weeks of my summer break on reading philosophy. Since I had no actual programming work to do, I decided to explore something new to me: web scraping. Web scraping is the (automated) retrieval of data from websites. If done properly, you can gather a large amount of information from a great variety of sources without any manual labour. This is for example essential for websites that compare prices, let’s say for hotels or various travel tickets. In my case, despite some fantasizing about fun projects, I do not (yet) have a useful application in mind. Just for practice I decided to start with something simple: extract all blogs from my own website, and organize them nicely in a folder on my computer.

Since I’m absolutely new to this topic myself, this blog post is intended as a starters tutorial of sorts. To get started, we need some Python modules. This script is written for Python 3. The module requests (version 2.19.1) is needed because we need our script to send a request to a website to get its data, without having to open a browser ourselves. Once we have this data it is a huge unreadable mess, so we need something to parse it and recover some of its original structure. The module BeautifulSoup (version 4.6.0) does exactly that: it knows its way around HTML and XML, and it will provide us the data we’re interested in if we ask it nicely.

import requests as req
from bs4 import BeautifulSoup as bs
import os

We now need to give the script some necessary information: a website url of our website of interest, and the current directory we are working in so the script knows where to store the scraped blog posts. This script is only suitable for scraping my blog, and would need to be rewritten for other websites. For complex applications, you would have to ‘crawl’ the web to find suitable urls. In this case, I know my website and where to look. If we want to scrape blog posts, we first need to know the names of all blog posts because I want to save their contents in a text file with the right name, and secondly need to find the url of each and every blog post. Luckily, I can kill two birds with one stone (poor birds), because I have a web page called ‘archives’ that is a comprehensive list of all blog post names that also contains links to their respective web pages.

So first we get the data of this ‘archives’ page with the requests module, and then let BeautifulSoup index its contents by creating a nice ‘soup’ of the requested data. From this soup we can extract the ingredients we want, which are in this case all urls from the blog posts. But we have to be precise about what we want. If you go to the archives page yourself and inspect the webpage’s html using your browser, you will see that all links to the blog posts are of the class “permalink”. Therefore, we can retrieve only the links we want by asking the soup to show us all html data of class “permalink”.

base_url = "https://edwinwenink.xyz/archives/"
script_dir = os.path.dirname(os.path.abspath(__file__))

# Find the URL's of my posts
r = req.get(base_url)
soup = bs(r.text, "lxml")
links = soup.find_all(class_="permalink")

We now have a list of links. Every link contains text shown on the web page (i.e. the title of the blog post) and the url to which it refers (which we need for navigating to the proper web page). Because I do not only want to scrape blog content blindly, but also organized all scraped text in a text file with the proper name, I will save both the title and url of each blog post. BeautifulSoup knows how links work, so for each link we can simply retrieve the actual url reference entered after ‘href’ tag, and the text itself as such:

# Record url and name of each blogpost
blog_urls = []
blog_names = []
for link in links:
    blog_urls.append(link.get('href'))
    blog_names.append(link.text)

Now that we have the urls of all blog posts, we can simply iterate over them to apply the scraping process, which is similar to how we scraped the ‘archives’ page. We are interesting in the parts of the blog that contain content, which are always contained within the p html tag. I wrote some extra code for saving everything to disk in an organized manner. For each blog, we select the right blog name from the names we saved before, and use it as the title of the .txt file we create. Other than that, we need to know where to save the files. I use the os module to create an appropriate path and make a directory called ‘Scraped Posts’ to save all the blog post contents in.

for i, url in enumerate(blog_urls):
    r = req.get(url)
    soup = bs(r.text, "lxml")
    content = soup.find_all('p')

    # Create file to save scraped blogposts
    filename = blog_names[i]+".txt"
    path = os.path.join(os.path.sep, script_dir, 'Scraped Posts', filename)
    os.makedirs(os.path.join(script_dir, 'Scraped Posts'), exist_ok=True)
    target_file = open(path, "w")
  
    # Write the scraped blogpost to file on disk
    for text in content:
        target_file.writelines(text.get_text())

Voila! Could this have done better? Yes, surely. But perhaps it is nice for anyone wanting to try out web scraping to see how another beginner approached it during a casual late-night programming session.

Reve's God and the Paradox of Intimacy

Gerard Reve was quite infamous for the enigmatic world view that speaks throughout his novels, in particular for his singular religious experiences that are almost always sexualized, and for the (homo)sexual acts that seem to be rituals in a partly mythological and partly Christian lifeworld. Add to all of that a dash of sadomasochism, and it becomes easy to understand how being a fan of Reve can seem like participating in some secret religion.

The prime example of his controversy is the scene in which he describes having sex with God, incarnated as a one-year grey mule, in his book “Nader Tot U” (Closer To Thee), resulting in Reve being sued for blasphemy by a member of the Dutch parliament. Initially Reve was found guilty but was not punished, and amazingly Reve contested this verdict in High Court and decided to deliver his defence himself. In this defense, he argued convincingly that the scene for which he was being sued was in fact, despite its seemingly offensive sexual nature, an expression of a genuine conception of God.

“God is het diepst verborgene, meest weerloze, allerwezenlijkste en onvergankelijkste in onszelf. (…) ik vermag niet in te zien waarom dit Godsbeeld minder recht op expressie zou hebben dan dat van bij voorbeeld de emanente God der wrake, die mensen tot het bedrijven van zonden predestineert, om ze vervolgens voor deze zonde voor eeuwig te verdoemen.”

Contrasted with the transcendent God of the Old Testament, an archetypical father figure that “predestines humans for a sinful life and then punishes them for it”, the God of Reve is understood as the most concealed, the most defenseless, and yet the most essential part of human being. In this essay, I propose to understand this in terms of intimacy. I am inspired by an insight of the Dutch philosopher Cornelis Verhoeven in his essay “Een aanslag op de intimiteit” (“An attack on intimacy”): “Het meest elementaire is maar in zeer geringe mate ons bezit en ons recht; het is even onmogelijk het te geven als het te veroveren” (my translation: “The most elementary is only in a very limited degree our possession and our right; it is just as impossible to give it as it is to conquer it”). Intimacy is of this category. Intimacy cannot be enforced, or even given without losing its intimate character; it is instead an event that one undergoes and leaves none of the parties unaffected.

Intimacy is impossible without vulnerability. That is why intimacy to me seems to be an interesting perspective on Reve’s religous writing, because in his relation to God he requires God to be equally vulnerable (and equally affected by the darker aspects of a love relation) as the human seeking Him. The intimacy between God and man is such, that in seeking God man finds the essence of his being, but also vice versa, that only in seeking the human God creates himself.

In the poem ‘Dagsluiting’ (the final prayer), also included in ‘Nader Tot U’, Reve writes:

Eigenlijk geloof ik niets
en twijfel ik aan alles, zelfs aan U.
Maar soms, wanneer ik denk dat Gij waarachtig leeft,
dan denk ik, dat Gij Liefde zijt, en eenzaam,
en dat, in zelfde wanhoop, Gij mij zoekt
zoals ik U.

A lot of readers of Reve tend to interpret his religious writing in terms of irony only, but I think that is an oversimplification. Reve’s writing is reactive, provocative, emancipating, but his ironic relationship with faith has a deep seriousness to it. If God is truly intimate, that is, concealed, defenseless, then his meaning cannot be communicated straightforwardly: intimacy disappears when it is illuminated and put on display as an active involvement. In the sphere of intimacy, he has to be named without being named, communicated without transforming the radical passivity of a shared touch into a digestible thesis. Reve’s irony prevents at all times that God becomes a closed off idea. So instead of being inconsistent with a genuine religious experience, it seems to me that Reve’s irony is to the contrary the suitable way of expression: the sphere of intimacy with God can only be hinted at, brought forward in a concealed manner, allowing not only doubt about the genuineness of this religious experience from others, but also by Reve himself (“I do not really believe anything / and doubt everything, even You”). Intimacy implies a vulnerable passiveness, a defencelessness against suffering, uncertainty, despair, desire, lust… it is human, all too human. At the same time, there is also no intimacy without some form of communication. A potential counterargument to my interpretation could be that is not possible to have an intimate relationship with someone whose very being you doubt. But Reve’s God is a God of the heart, not the vacuum of a negative theology or the God of philosophers, and it is perhaps precisely through the very experience of doubt and of suffering that Reve feels intimate with God because He is thought to share in his suffering and desperation.

Because Reve defines God as the utmost intimacy of human being, God itself is not omnipotent, but a priori this passive openness to suffering itself. “God is Eenzaam, en Hij is een Lijdende God” (God is Lonely, and He is a Suffering God), says Reve in ‘Het Boek van Violet en Dood’, and “Als God drinkt, dan is dat niet zonder reden.” (And if God drinks, it is not without reason). That is why Reve’s God is so tragic: in this intimate relation, God desperately requires redemption by the human just as much as the human requires redemption from God (“But sometimes, when I think that You live truthfully, / then I think, that You are Love, and lonely / and that, in similar despair, You seek me / as I seek You”). That Reve often identifies God as Love with a capital ‘L’ is yet another indication that God is the imperfect, all too human, two-unity of desiring and suffering. God and human are essentially interchangeable in their sin and longing for redemption. Because Reve’s imagination of Love is sadomasochistic, the intimacy I speak of here does not presuppose God’s comfortable presence, or a peaceful dialogue. Instead, the sadomasochistic nature of this religious intimacy includes a certain cruelness and silence of God.

A consequence of this extreme intimacy is that God is not something beyond this world, but rather the extreme and essential expression of it. Any notion of an after-world is therefore completely irrelevant for Reve, as God is an tragic expression of this life, of perpetual desiring and suffering. I think that Reve’s religious experience cannot be separated from a pessimism that is beyond chagrin, but instead has metaphysical significance. Therefore I cannot help but see similarities in the pessimism of Reve and that of Schopenhauer, whose pessimism even resonates in the most fundamental claims of his metaphysics: as the world is essentially Will, a perpetual desiring with no other target than itself, and as desire is the ground of suffering, the world turns against itself and is, in its metaphysical ground truth, suffering. Only in Reve’s later works, and interviews, have I found references to Schopenhauer that nevertheless strengthened this perceived connection.

To conclude, in Reve’s universe religion and sexuality enter a mystical union. What strikes me is that now that sex increasingly loses its taboo, it is also increasingly represented as a fun activity. But it is the passivity, the receptive capacity to be touched by someone, beyond our control, that makes sexuality intimate. In these times where sex is normalized and the intimacy of love is instead almost a taboo, a scary “private” resistance to the all-seeing eye of the internet and the media, a unique mind such as Reve’s is all the more interesting. In Reve’s work, sexual acts are never flat out sex. Instead, they are his intimate prayers.

In contrast to the opinion of many that Reve’s sexual utterances in his work are an unnecessary or offending distraction – take for example the poem “Revelation” where Reve says “happy tidings:\ God jerked off while He thought of me”) – I think they are all very curious tributes to an intimate relationship. They can be politically incorrect, compulsory, ugly, sorrowful, idolizing… in other words, they display sexuality not as a rational activity, but as the preparedness to lose control in the devotion to an other. This is the paradox of intimacy that Verhoeven notes in his essay. In the intimate region where we belong the least to others and can close ourselves off the easiest from them, we are simultaneously no masters over ourselves and are the most dependent.

Writing a letter the cool way... for free

Markdown and Pandoc are the preferred tools around which I design my workflow. For practically all writing I do, they get the job done properly, quickly and for free. For some applications with more delicate layout requirements, such as for example a letter or a resume, writing in Markdown is a bit limited. In those cases, if you subscribe to the philosophy that content and layout should be separated, you end up with writing in LaTeX. However rewarding the results of writing in LaTeX are, when you are used to writing in Markdown it just feels cumbersome. When I write something, I want to focus on the text with as little distraction as possible. In LaTeX I always end up googling because I made a small syntax error somewhere that prevents my document from compiling.

Luckily, there are some amazing people on the web with similar workflow ideas, and that are kind enough to share the hard work they put into designing theirs. I came across the website of Mattia Tezzele, who made LaTeX boilerplates for some of those scenarios in which more intricate layout is required, namely for letters, resumes, and invoices. I have seen more similar boilerplates, but these are silky smooth and easily the cleanest I have seen. Most importantly, they fit perfectly with my current workflow. Writing is done in Markdown, and the bits that require special formatting are read in using a YAML header, which is exactly the method I also currently use for these blogposts. On top of all that, everything is well documented, and in case someone is unfamiliar with any of the parts of this workflow, resources for further reading are also provided. Did I mention everything is open source and for free?

Here’s a snap of me writing this post:

Let’s give it a try. Mattia Tezzele provided a template markdown file for the first letter. Filling in the fields of sender and addressee are straightforward. Personally I only had to change one aspect of the template to make it compile. The boilerplate uses the fontspec LaTeX package to select fonts from your own system. In the template ‘Courier’ was for example mentioned as one of the fonts, but for my specific system (Arch Linux) that naming was not accepted. On top of that, I also don’t think I had any of the default fonts installed on my system. I decided to keep it simple and choose a font from the large database of freely available Google fonts.

Since the fontspec package uses system native fonts, I only needed to find the correct name of the font I wanted in my system. Fonts are saved in /usr/share/fonts. We could keep it relatively simple and look for fonts in the TTF folder, which contains a human readable list of fonts. Even simpler is to look for fonts on the Google fonts website, but it might occur that after a long search you pick a nice font you did not install on your system after all. I wanted to keep my letter style retro, so I picked the Inconsolata font (which I then also decided to use for this blog). Now all we need to do is find out under which name this font is known in the system. To find out, I ran:

fc-list | grep Inconsolata

/usr/share/fonts/TTF/Inconsolata-Bold.ttf: Inconsolata:style=Bold

/usr/share/fonts/TTF/Inconsolata-Regular.ttf: Inconsolata:style=Regular

As a font, I then included Inconsolata:style=Regular in the YAML header of my letter, as you can see in the screenshot above. Another minor issue is that my system complained about ‘English’ not being a valid language choice, so I changed it to en-US. The last thing you want to do for sure is make a pdf of your very own digital signature. I do not have hardware to draw on the pc, so instead I took a scan of my signature from my phone and edited it until it looked decent. I will show an example letter, but for privacy reasons I’ll skip on using my own signature and instead will use the one provided with the example fictional letter from github, which is of Nietzsche. To match the signature, I wrote a fictional letter of our good old friend Friedrich:

Click Me For A Cool Letter

For fast compiling using pandoc, you can use the makefile included with the download of the boilerplate. I instead made two quick bash scripts, one for creating a new letter (using a fresh copy of the letter template we by now customized to our needs and wishes), and another script to call pandoc to create a nice looking pdf.

For drafting a new letter (note that I saved my template in a folder called LetterTemplate):

#!/bin/bash

# Copy the template to start a new letter

filename=$(date +%y-%m-%d_new.md)
echo $filename
cp -n LetterTemplate/lettertemplate.md $filename

And for writing it as a pdf to a folder called ‘output’:

#!/bin/bash

# Write the markdown letter to pdf using pandoc and xelatex

if [ -f "$1" ]; then
    file=$(basename "$1$")
    filename=${file%.*}
    pandoc "$1" -s -o ./output/"$filename".pdf --template=letter.tex --pdf-engine=xelatex
fi

One last note: notice that when calling pandoc you need to place the correct boilerplate (here called ‘letter.tex’) in the templates folder at ~/.pandoc/, and that this boilerplate only works with the ‘xelatex’ pdf-engine due to the fontspec package.

Have fun writing!