In the world of showing off, there is alongside ‘Does it play Doom?’ that other classic of ‘Does it play Bad Apple?’. Whereas either would be quaint in the context of the Vim editor, this didn’t deter [Nolen Royalty] from making Vim play the Bad Apple video. As this is a purely black and white video, this means that it’s possible to convert each frame into a collection of pixels, with regular expression based search and custom highlighting allowing each frame to be rendered in the Vim window.

The fun part about this hack is that it doesn’t require any hacking or patching of Vim, but leans on its insane levels of built-in search features by line and column, adjusting the default highlight features and using a square font to get proper pixels rather than rectangles. The font is (unsurprisingly) called Square and targets roguelike games with a specific aesthetic.

First 6,500 frames are fed through ffmpeg to get PNGs, which are converted these into pixel arrays using scripts on the GitHub project. Then the regex search combined with Vim macros allowed the video to be played at real-time speed, albeit at 120 x 90 resolution to give the PC a fighting chance. The highlighting provides the contrast with the unlit pixels, creating a rather nice result as can be seen in the embedded video.

8cc.vim is a C compiler that exists as pure Vimscript. Is it small? It sure is! How about fast? Absolutely not! Efficient? Also no. But does it work and is it neat? You betcha!

Ever typed :wq to write the buffer and exit in Vim? When you do that, you’re using Vimscript. Whenever one enters command mode : in Vim, one is in fact using a live Vimscript interpreter. That’s the space in which this project exists and does its magic. Given enough time, anyway.

Vimscript itself was created by [Bram Moolenaar] in 1991. The idea was to execute batches of vim commands programmatically. It’s been used for a variety of purposes since then.

8cc is a lightweight C compiler that has been supplanted by chibicc, but that doesn’t matter much because as author [rhysd] admits, this is really just a fun concept project more than anything. It may take twenty minutes or more to compile “hello world”, but doing it entirely from within Vim is a trip.

The ways in which we interact with computers has changed dramatically over the decades. From flipping switches on the control panels of room-sized computers, to punching holes into cards, to ultimately the most common ways that we interact with computers today, in the form of keyboards, mice and touch screens. The latter two especially were developed as a way to interact with graphical user interfaces (GUI) in an intuitive way, but keyboards remain the only reasonable way to quickly enter large amounts of text, which raises many ergonomic questions about how to interact with the rest of the user interface, whether this is a command line or a GUI.

For text editors, perhaps the most divisive feature is that of modal versus non-modal interaction. This one point alone underlies most of the Great Editor War that has raged since time immemorial. Practically, this is mostly about highly opiniated people arguing about whether they like Emacs or vi (or Vim) better. Since in August of 2023 we said our final farewell to the creator of Vim – Bram Moolenaar – this might be a good point to put down the torches and pitchforks and take a sober look at why Vim really is the logical choice for fast, ergonomic coding and editing.

First, There Was Vi

Text editors weren’t originally really much of a thing when it came to home computers, with the need to edit text and configuration files the most pressing on larger UNIX systems. This was the world in which the vi editor (short for ‘visual’) saw the light in 1976, when Bill Joy created it as a visual mode for the ex line editor that worked better on a teleprinter. Bill Joy did admit to being strongly inspired by the modal Bravo editor, which was created at Xerox PARC in 1974 for the Alto Executive operating system.

As the standard editor in BSD Unix distributions and part of the Single UNIX Specification, vi became well-known and despite it being proprietary software, demand grew for a version that would work on home computers. This turned out to be Stevie (ST Editor for Vi Enthusiasts), originally written by Tim Thompson for the Atari ST in 1987, but later ported by Tony Andrews to UNIX, OS/2 and Amiga in 1988. It was this Amiga port that Bram Moolenaar – as an Amiga user – would pick in 1991 as the basis for what would become Vim.

Initially ‘Vim’ stood for ‘Vi IMitation’, but after the project picked up speed and gained many new features that made it much more than ‘just vi’, it became ‘Vi IMproved’, or ‘Vim’ for short. Even though Bill Joy had by then joined the Dark Side with his entry in the Church of Emacs, this did not mean that the mode-based editing approach first coined with the Bravo editor at Xerox PARC was now on the ropes. Instead Vim is still the editor you’ll usually find installed by default on Unix, BSDs, Linux distributions and others, whether in its vi-compatibility configuration or full Vim glory.

Strain Modifier

Vim is the canonical mode-based editor. Perhaps the most straightforward way to describe the difference between mode-less and mode-based text editors is in the way that modifier keys are used. If you want to perform commands with a mode-less editor, you have to use the Alt, Ctrl, Shift, Meta, or Cmd and some of the alphanumeric keys simultaneously to form the key combination that triggers the desired command. Depending on the number of these commands are configured this can mean simultaneously hitting a mere two keys all the way up to five or more in some kind of claw-like death grip. In the case of Emacs the common issue with a sore finger is referred to as an ‘Emacs pinky‘ from overextension to the Ctrl key.

With a mode-based editor, you hit the configured key (like ‘Esc’) to leave the Insert Mode and enter Command Mode where you type out the string with the command. From a repetitive strain injury (RSI) point of view, it ought to be somewhat obvious that the latter approach puts less stress on one’s hands and wrists as they can remain mostly on the home row, rather than having to contort continuously to reach for modifier keys to form uncomfortable combinations, or even shift your position for that bane of ergonomics: the mouse.

Beyond the inevitability of accessing the Shift key now and then in order to capitalize a letter here and there, or to hit Caps Lock for that bit of SQL syntax, your hands should remain on the home row when using a mode-based editor like Vim, with your weak pinky rarely having to exert a trembling reach all the way over to the Alt and Ctrl keys. When you are done typing in whatever text had to be typed in Insert Mode, you move your left hand slightly over to hit the Esc key to enter Command Mode, which is also a nice change of position that allows for stretching your hands some.

Vim As IDE

Although Vim started as a text editor, it has over the decades collected many features which are generally associated with integrated development environments (IDEs). This include syntax highlighting, code folding, integration with toolchains and a robust extension ecosystem that allows a user to turn a basic Vim installation into an IDE for whatever target language and environment they need.

In order to get started with configuring Vim as an IDE, you only have to follow one of the countless tutorials you can find all around the internet, owing to just how many people use Vim exactly for this purpose. Some mention trying out countless other IDEs and editors, only to come back to Vim. One thing that is highly attractive here is how transparent and configurable it is. You can quickly check and configure settings in the plain text configuration file, and share these settings with others, or simply back up your entire Vim configuration, which is very convenient when switching between systems.

Finding additional plugins for Vim can be a bit of a chore if you’re looking for something specific, but the official scripts database on the Vim site, as well as as sites like Vim Awesome can help with sifting through what’s available. There are also plenty of recommendations by Vim users on which plugins they figure are the best for developers and sysadmins. Although perhaps not as glitzy and user-friendly as something like Visual Studio Code, Vim will happily run on the command line, even inside a screen session via SSH on a remote server, without requiring a gigabyte of RAM and lugging a browser-sized attack surface along with it.

:wq

For the average computer user, vi and Vim, Emacs and mode-based editors are something that they will likely never come across in their daily, Windows and MacOS-based experience. To them these sound and look like tools used by hackers, as they sit in darkened rooms in front of multiple screens with text busily scrolling past in terminals. Yet when the Editor War first began to pick up speed, that was basically all that computing was like, whether in DOS, CP/M, UNIX, or the various BASIC runtimes including that of the pre-MacIntosh Macs.

In that era nobody was quite certain what the best way to create a user interface was, with even the GUIs of Windows 1 through 3.xx looking quite bizarre to today’s generations. These days we have more or less settled on a few standard ways of interacting with computers, but as the ongoing strife between the Church of Emacs and the Enlightened of Vim shows, nothing is ever fully settled, even as both sides bring their best arguments to bear.

Regardless of what the future of computing will look like, we all owe Bram Moolenaar a thanks for his role in giving us Vim, and kickstarting the community around it.

Vim is the greatest or the worst text editor of all time, depending on the tribe you’re in. Either way, members of both camps can appreciate this build from [Chris Price], which uses a foot pedal to ease operations for the user.

The basic concept was to use a pedal to enable switching between normal and insert modes. In Vim’s predecessor, vi, switching modes was easy, with the ESC key located neatly by the Q on the keyboard of the ADM-3A terminal. On modern keyboards, though, it’s a pain, and so a foot pedal is a desirable solution. In the Vim world, it’s referred to as a “Vim clutch.”

The build used a cheap pedal switch sourced from eBay, into which a Raspberry Pi Pico was installed. The Pico was hooked up to the switch contacts, and programmed to act as a USB HID device. When the pedal is pressed down, the Pico sends an “i” keypress to enter Vim’s insert mode. Releasing the pedal has the Pico send a “ESC” keypress to return to normal mode.

Those that use Vim on a regular basis would likely appreciate the productivity improvements of such a device. Plus, there’s some ergonomic benefits to not having to strain one’s hand over to reach the ESC key. Of course, it’s an old-school solution, but there’s still something so compelling and next-level about having a foot pedal hooked up to one’s dev rig.

Linux users–including the ones at the Hackaday underground bunker–tend to fall into two groups: those that use vi and those that use emacs. We aren’t going to open that debate up again, but we couldn’t help but notice a new item on GitHub that potentially negates one of the biggest complaints non-vi users have, at least for vim which is the most common variant of vi in use on most modern systems. The vim keybinding makes vim behave like a “normal” editor (and to forestall flames, that’s a quote from the project page).

Normally vi starts out in a command mode that it calls normal mode. Pressing a key will execute an editing command, unlike most other modern editors which just insert characters into the open file. For example, pressing x will delete a character. This surprises most people who aren’t familiar with vi. In all fairness, there are other older editors that work this way, but they usually were not screen-oriented.

We keep waiting for the emacs/vi holy war to die off as the old guard retires or forgets how to use computers. You’d think more people would be using kate, atom, or some other really modern editor. But it doesn’t seem to die down–at least not around here.

We suspect the author is going to get threatening e-mails and won’t be able to go shopping without a disguise as the vi faithful will surely find this an abomination. Of course, emacs has several vi emulation modes, and no one has had any more than a car keying over that, that we know of.

We won’t revisit the editor war because we already have covered both sides of it. We’ll just try to get along, at least here in the bunker.

As a rule, I try hard not to get sucked into religious wars. You know, Coke vs Pepsi. C++ vs Java. Chrome vs Firefox. There are two I can’t help but jump into: PC vs Mac (although, now that Mac has turned into Unix, that’s almost more habit than anything else) and–the big one–Emacs vs vi.

If you use Linux, Unix, or anything similar, you are probably at least aware of the violence surrounding this argument. Windows users aren’t immune, although fewer of them know the details. If you aren’t familiar with these two programs, they are–in a way–text editors. However, that’s like calling a shopping mall “a store.” Technically, that’s correct, but the connotation is all wrong.

Like most religious wars, this one is partly based on history that might not be as relevant as it used to be. Full disclosure: I’m firmly in the Emacs camp. Many of my friends are fans of vi–I try not to hold it against them. I’ll try to be balanced and fair in my discussion, unless I’m talking about my preference. I don’t have to be fair when it comes to my opinions. Just to be clear: I know how to use vi. My preference isn’t based out of not wanting to learn something new.

The Big Differences

Superficially, there is one big difference between the two editors. Vi has the concept of a mode. Most commands are just ordinary letters (for example, the I key enters insert mode). The problem with that, of course, is that if you start typing in the wrong mode you either get command characters in your file or you issue lots of random commands.

Emacs works more like a normal text editor. When you type normal characters they go into the current file. Commands use special prefix characters like Control+X or Escape. Sure, you might have a normal letter after a prefix (Control+X C, for example) but that’s only for the short duration of the command.

The Case for Vi

The best argument, in my opinion, for vi is that it is fairly lean and it is on just about every Unix-like system you’ll ever encounter. There are other “standard” editors, but they are not screen-oriented and are very painful to use. That’s why I know how to use vi.

You’ll often hear the argument that vi is lean and Emacs is bloated. That’s somewhat true, although modern versions of vi (like vim) are not very skinny, either. Generally, vi starts faster than Emacs, all other things being equal (although you can bog down either one). However, there’s a reason for that, as you’ll see in a minute.

The Case for Emacs

If it were just the fact that Emacs always lets you type plain text, it really would be just a matter of personal preference. However, I have noticed that there are two things people who are passionate about Emacs have in common. First, they are people who either predate widespread use of X11, or that could not use it for one reason or another. Second–and this is a secondary effect–they tend to be touch typists.

The first reason is because Emacs is a text-based window manager. Sure, the most common thing to have in a “window” is a text editor, but Emacs can also display file managers, games, e-mail clients, web browsers, and plenty of other window types. You can even run a shell inside an Emacs window. The most recent version even has a WebKit-based browser. You can watch a YouTube video from within Emacs. If YouTube doesn’t excite you, maybe you’d be more impressed by opening GitHub, Google, or Hackaday.

This leads to the popularity, I think, among touch typists. Being able to create, manipulate, and switch windows without taking your hands off the keyboard is very valuable to fast typists.

Granted, today, you don’t need a text-based windows manager. You could use GNU screen, although it works a little different. But most of us use a GUI desktop now and it is less important to have Emacs manage windows for shells, browsers, and so forth. Even if you want keyboard-driven window management, there are solutions for that too.

If you are a hardcore hacker, Emacs has one other advantage: it is fully programmable using a version of LISP. That’s a dual-edged sword. On one hand, Emacs an do anything. On the other hand, you can go deep down the rabbit hole making custom set ups.

So What’s the Answer?

So maybe it really is a matter of personal preference. But to me, its still Emacs all the way. One thing I’ll point out: It is pretty easy to make Emacs act very much like vi, but the reverse isn’t possible in any meaningful way. Of course, if you are under a certain age, you probably use some GUI editor like sublime or Eclipse and are scratching your head that an editor war even has its own Wikipedia page (not to mention the flurry of comments this post will probably launch).

If you do log into an embedded Linux system that doesn’t have enough horsepower (or connection bandwidth) to support a GUI, both of these editors can help you be more productive. However, Emacs can also give you some measure of multitasking windowing, even over a non-GUI SSH or telnet connection.

compact keyboards that do away with a third of the keys you would usually find on a normal-sized keyboard are all the rage now, but for [jonhiggs], they weren’t good enough. There is a long tradition of Unix shortcuts these compact keyboards don’t pay attention to – CTRL-A being the Home key, and CTRL-D being the Page Down key. To fix this horrible oversight of Unix history, [jon] tore apart one of these compact keyboards, rewired the switch matrix, and made his own perfect keyboard.

The keyboard [jon] is using is a Filco Minila, a very nice and high quality keyboard in its own right.  After mapping out the switch matrix, [jon] wired all the switches up to a Teensy 2.0 loaded up with the TMK firmware. This is a pretty standard way of building a custom keyboard, and [jon] could have just cut a switch plate and installed panel-mount switches and wired up the matrix and diodes point to point. The case for the keyboard is constructed out of Lego.

Because this is a true, modern Unix keyboard, [jon] needed to connect this keyboard to a box running his *nix of choice. He’s doing this in the most future-retro way possible, with an Amazon EC2 instance. This project isn’t done yet, and [jon] is hoping to add an ARM dev board, an iPad Retina display, battery, and SSD, turning this into a completely homebrew laptop designed around [jon]’s needs.