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.
Continue reading “On Vim, Modal Interfaces And The Way We Interact With Computers”
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.
Older readers and those with an interest in retrocomputing may remember the days when a computer might well have booted into a BASIC interpreter. It was simultaneously a general purpose device that could run any software it would load, and also a development environment. Not something that can be said for today’s development boards which typically require a host computer on which to write code. Have we lost something along the way? Perhaps an answer to that question can be found in [lurk101]’s self-hosted development environment for the Raspberry Pi Pico.
It presents itself as a shell, with a flash file system, a port of the vi editor, and a C compiler. We might think of vi as being more at home on a UNIX-derived system, but in this case it’s a port of the vi included in BusyBox. Meanwhile the compiler comes from amacc project.
Of course, this still requires a terminal of some type which in practice will mean a host computer. But the feat is nevertheless an interesting one, and we can see that it might not be impossible given the Pico’s surprising versatility to being some of the terminal features onto the chip itself.
It’s worth noting that this isn’t the first attempt we’ve seen to put a command line interface on a development board.
If you grew up with Unix systems like we did, you’ll be sorry to hear the news: vi, the noble text editor that has served us so well these 40 years, is going away — from many GNU/Linux systems, anyway. As of this writing, GNU/Linux Mint, Debian, Ubuntu, and OpenSUSE — four of the five most popular GNU/Linux distributions — have all announced that they will no longer ship the ‘vi’ editor as part of their base installs. For those of us who got our start in the punched-card era and still think of files as a collection of lines instead of a stream of bytes, this is a major blow. But, we can all take some comfort in the fact that, at least for now, the stripped-down version of vim synonymous with vi on these systems will continue to be available from package repositories.
The reasons for the move aren’t entirely clear to us, but from what we can see on the GNU/Linux mailing lists, the confusing modal interface and the fact that novice (and many seasoned) users can’t figure out how to save a file and exit the program seem to have influenced the decision. Also cited were support changes expected as GNU/Linux gains in popularity. As the user base expands to include less technically-savvy individuals, fewer people will be able to fix their constant boot issues, which is the primary use-case for vi. Replacing the self-help model will be a support infrastructure where users can take their machines to “GNU/Linux Geniuses” who will solve the problems for them.
Continue reading “Bye Bye Vi: GNU/Linux Distros Drop Support”
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.
Continue reading “VIM Normalization”
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.
Continue reading “Editor Wars”
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.