Einar's blog
09 mars 2023

Why do webpages with text waste so much of my screen space?

The Arch Wiki changed its design some months ago from text and a sidebar that floats to fill the size of the screen to the content now only being inside a narrow box that takes up only parts of the width of a larger screen. The Arch wiki is not alone in making text-based content visible only inside a narrow box in the middle of the screen. It is a general trend in web-design when the content is text and images and is very common on blogs. It is also used in the Reading mode in Firefox. The idea is that it should somehow be easier to read the text when it is centred and narrow. I do not know exactly why people think this is the case, but many people do. There might be user interface research to suggest people read faster in a narrow column, or it might just be based on how books and newspapers with columns were traditionally laid out. I am not a user interface designer, so my knowledge is limited to my own thoughts and experiences. Even so, I know I am not alone in being annoyed by this trend in web-design, so I thought I'd write a few words about it in the hope that I could convince some people to rethink the use of the max-width attribute in their CSS file.

narrow_text.jpg

I think the idea that it is easier to read text in a narrow column is just balderdash. At least to me, the disadvantages of a narrow columns are far greater than any possible advantages and I do not read any faster when the text is laid out like this. The disadvantages of narrow text columns on a wide screen are many. Firstly, you have to jump lines more often which makes it easier to loose where you are in the text. Secondly, you have to scroll more often which interrupts the flow of reading the text with unnecessary movement. For most people, this involves lifting their hands from the keyboard to a trackpad or mouse. For more keyboard-centric users, it involves using arrow keys or PageDown, the middle button and a trackpoint, ctrl-n (Emacs keybindings) or j (Vim keybindings). How this is done depends on the browser and the hardware. More keypresses (or mouse actions) makes digesting the information in the text into a slower process with more interruption from actual reading than necessary and wastes time and energy. I also find it aggrevating to have to scroll more often than necessary. Thirdly, it wastes a lot of space on the screen that could have been used for content but is now just empty background. Fourthly, it disregards the choice of screen size and window size the user has made. Some people like very wide screens with a 21:9 ratio while others like 16:9, 3:2, 16:10, or 4:3. Personally, I feel that for smaller laptop screens like my 12,5 and 14 inch laptops, a less wide aspect ratio like 16:10 or 4:3 is preferable, but for a larger external screen, 16:9 is usable (and much easier to find used at a reasonable price) because you have enough pixels of height with a larger screen at normal pixel densities to avoid too much scrolling even if it is 16:9. Additionally, the width of the screen is not necessarily the width of a window. The user can choose for themselves how wide a window they would like to read the text within. For those of us using tiling window managers, splitting the screen into smaller areas is just a keypress away. I don't need a web designer to choose how narrow my window should be for me when I use a smaller window, and when I want a wide window for the text of a website, I definitely would prefer not to be limited to a narrow strip in the middle to avoid unnecessary scrolling, space waste and moving lines more often. If the content just resized to fit the window, maybe with some small margins to look less cluttered, that would be preferable to me.

I cannot think of any advantages to narrower columns of text on a webpage. Human vision is wider than it is tall and that is the argument many give for widescreens in the first place. It is also why films and pictures usually are wider than they are tall unless shot in the portrait orientation because the human body is in that orientation or because the display medium is going to be a smartphone. You do not need to move your head when reading text filling the width of a wide screen unless the screen is really large and you are really close to it, so that is not an argument against letting the text flow wider. For computer screens, most people use screens small enough that you never need to move your head. At normal computer screen viewing distance (which is different than for instance TV viewing distance and smartphone viewing distance) that means that anything smaller than a 27 inch screen is small enough. I use a 25 inch 1440p external screen often and it is definitely small enough that I never need to move my head to read a long line of text. You do have to move your eyes no matter how wide the column is, so making it narrower does not mean any less eye movement, just more up-down movement to change lines instead of more left-right movement. Smartphones are taller than they are wide when held normally, so maybe mobile-friendly design is the motivation, but if the text would just flow to the width of the screen minus a small margin, that would work just as well on phones as on tablets, two-in-ones, laptops and desktops and not annoy users of any device.

I think narrow columns were initially used in newspapers because newspapers in the past often were not in the tabloid format and therefore a bit of narrowing was useful because usually you would have to fold the paper to be able to hold it, but for webpages today, I just don't get why people want less content, more line breaks and more scrolling. This trend is actually a good reason to use terminal-based web browsers that disregard CSS or use custom CSS in a more mainstream browser. There might be reasons I do not know for making content only fit a narrow strip in the middle of larger screens that do not apply to my use of the web, but for me, this trend is definitely annoying. I have changed the CSS for this website to reflect this view.

19 feb. 2023

Non-free firmware in Debian 12 Bookworm

I have spent a bit of time trying to find the firmware-iwlwifi package with the Intel Wifi driver for Debian 12 Bookworm (the next Debian release, currently in testing). I tried all the usual things like enabling the contrib and non-free repos, but could not get it installed. I looked at the Debian Wiki and it gave me a link to packages.debian.org that led me to the package, but only in older versions of Debian. When I tried to go to the same package in Bookworm, I found nothing. I thought maybe the files had moved to another package and tried apt-file, but with no success. After a lot of searching on the internet, I finally found out that non-free firmware files have been removed from non-free and a new repo called non-free-firmware is where they now live. After adding that repo, I could install the firmware-iwlwifi package. This information should be added to the Debian Wiki in the articles about firmware-iwlwifi and firmware, but I was unable to make a user profile on the wiki to add this information myself which is why I wrote this blog post.

Edit March 9th, 2023: From the Alpha 2 release of the installers, this non-free-firmware repository is added by default to your install, so my previous explanation here of how to enable that repo for new users is no longer needed. If you have hardware that does not need non-free software drivers, then there is no harm in removing this repo from the etc/apt/sources.list file and just use the main repo for a fully free software experience.

14 feb. 2023

I Love Free Software Day

I want to thank all the developers, contributors, translators, designers and project leaders who have given me so much great software on I Love Free Software Day! I also want to thank a harpsichordist from Bergen who many years ago showed me that GNU/Linux was a good alternative to Windows or MacOS. Even though I did not do anything about it at the time, some years later, curiosity led me to try out various GNU/Linux distros in VirtualBox on my Mac and that was the start of a gradual transition from Mac OS to GNU/Linux. I already used some free software like LibreOffice, Firefox and Thunderbird on my Mac and that helped ease the transition.

Free Software is about freedom. In practical terms for a normal user, it is very obvious how the users' interests is important for free software projects while non-free software often is more about forcing the users into usage patterns that strengthen the corporate interests of their creators even if it makes for a worse user experience. An example is how Microsoft tries to force people to use Bing, Edge and MSN by not respecting the user's browser and search engine settings when doing a web search from the start button in Windows 11. It makes advertising money for Microsoft, but it is very user-hostile, especially since the users already paid for Windows as part of the cost of their machine. This is just one small example, but there are many more.

I also like how I can help improve free software by contributing to projects I like. I have contributed money, bug reports, translations, feature requests and a bit of very simple code, and hope to do more of this in the future. It is also possible to influence the direction of a free software project by contributing to it. This puts the most active users in the driving seat. In a worst case scenario where a project goes in a direction people dislike, it is possible to create a fork since free software licenses give the freedom to modify a program and distribute your changes. A famous example is how OpenOffice was forked to create LibreOffice which is now the default Offie suite on most GNU/Linux distributions. (OpenOffice is no longer actively maintained.)

I also like how Free Software empowers me as a user to customize it to my liking and learn how to programme in the process. With Free Software, my computer is personal again. Not only can I choose between a lot of desktop environments or window managers to match my preferred workflow, I can also customize these further to my liking. While I prefer a tiling window manager with a keyboard-centric workflow without any panel or bar for maximum screen real estate for my programmes and a minimum of mouse clicks and movement to get things done, other people prefer a full desktop environment either of the more traditional type or a reimagination with new user interfaces like Gnome. GNU/Linux is modular enough to give us those choices by design. GNU Emacs is another piece of software that is very customizable and when you customize it, you also learn how the code of the program itself works since you customize it in the same language as it is made with by adding your own functions and modifying built-in variables. The documentation of the program is very helpful for learning how to do this. It was the first programme made by the GNU project and a prime example of the freedoms of free software put into practice. The numerous forks of it attests to the importance of those freedoms for people wanting to use parts of it or change it more to their liking.

Happy I Love Free Software Day!

26 nov. 2022

Elfeed with useful scripts

Elfeed is an RSS feed reader package for GNU Emacs. RSS is a standard for getting content like podcasts, video channels from LBRY and Youtube, Mastodon and Twitter, blog entries, news articles etc from the web without using a browser. Before I started using elfeed, I used Newsboat, a terminal program, as my RSS reader. I was inspired by Napoleon Wils0n to add scripts to Newsboat so I could launch videos from RSS feeds directly in mpv or download them with youtube-dl (and later yt-dlp). After I started using Emacs, I wanted to try to integrate most of my computing into it and I looked at the two built in feed readers before trying the highly recommended elfeed package. I liked it, so the next step was to find a way to get the same functionality I had in Newsboat in elfeed.

I don't know Elisp well enough to script this myself yet, so I looked online. I read up on the documentation for elfeed on GitHub and also found some inspiration on Reddit that I tweaked to make some elisp scripts to be able to hit m if I want to watch a video in mpv and M if I want to download it with yt-dlp to my "Nedlastinger" (Downloads in Norwegian) folder. I tried a couple of different solutions before I was able to get what I wanted. The suggestion from Reddit was to use start-process to launch an external process with the url from the entry as its argument. That worked well with mpv. For yt-dlp that was less successful and I also wanted to change directory to ~/Nedlastinger before launching the yt-dlp process so I read up on how to run shell-commands asyncronously and used that functionality instead. I also made certain that any shell command run asyncronously doesn't display a new window. (A "window" is a split within an Emacs "frame" (an X11 window) in Emacs parlance. Emacs is from before the Macintosh introduced the desktop metaphor's now common vocabulary (that Microsoft later copied in Windows), so it uses its own vocab for these concepts.) The reason why there are two scripts for each functionality is that I can use those keyboard shortucts both inside the view where you show the specific entry and in the view where you see all entries while one is selected.

;; Dette gjør at Async Shell Command ikke vises hver gang man kjører en shell kommando med & fra inne i Emacs 
(add-to-list 'display-buffer-alist
  (cons "\\*Async Shell Command\\*.*" (cons #'display-buffer-no-window nil)))

;; Gir meg muligheten til å bruke m i elfeed for å åpne en rss entry i mpv
(defun browse-url-mpv (url &optional single)
  (start-process "mpv" "*mpv*" "mpv" url))

(defun elfeed-show-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "m") 'elfeed-show-mpv-open)
(define-key elfeed-search-mode-map (kbd "m") 'elfeed-search-mpv-open)

;; Gir meg muligheten til å bruke M i elfeed for å åpne en rss entry i yt-dlp
(defun browse-url-ytdlp (url &optional single)
  (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &")))

(defun elfeed-show-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "M") 'elfeed-show-ytdlp-open)
(define-key elfeed-search-mode-map (kbd "M") 'elfeed-search-ytdlp-open)

Those scripts worked fine for video channels from LBRY and Youtube, but not for podcasts which use an enclosure url to give the url to the actual episode's video or audio while the general url field in the RSS entry is used for show notes. I tried searching for variables within elfeed with the built in self-documenting features of Emacs, but did not fully understand how to find the enclosure url. After some searching aorund the internet, I found a way to get the enclosure-url and recycled most of my previous code again with the new url to make two functions making it possible for me to listen/watch a podcast with mpv by hitting P and downloading it with yt-dlp with K. I only implemented this for one of the two views.

;; Gir meg muligheten til å bruke P i elfeed for å åpne en podcast (enclosure) i mpv
(defun elfeed-show-play-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (start-process "mpv" "*mpv*" "mpv" url)))

(define-key elfeed-show-mode-map (kbd "P") 'elfeed-show-play-enclosure)

;; Gir meg muligheten til å bruke K i elfeed for å laste ned en podcast (enclosure) med yt-dlp
(defun elfeed-show-dl-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &"))))

(define-key elfeed-show-mode-map (kbd "K") 'elfeed-show-dl-enclosure)

I have set my default browser with my environment variables to Firefox and even though I like Emacs' built in browser eww a lot for text-based content with the occasional picture, I want to keep Firefox as my default browser for now. However, when I read an RSS entry in elfeed and it does not supply the full blog post, it is nice to stay within Emacs and read the linked blog post with eww instead of launching a heavy external browser. So I had to make two functions for the two view modes for that as well. So for those RSS feeds that do not supply the full content, I just hit B and the content opens up in eww. There is built in functionality to open the linked content in the default browser by hitting b in elfeed, so whenever I want or need to open the content in Firefox, I just hit b. For some content that is dependent on JavaScript or is full of media, I sometimes use that built in function, but usually, I use B instead.

;; Gir meg muligheten til å bruk B i elfeed for å åpne en rss entry i eww
(defun elfeed-show-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "B") 'elfeed-show-eww-open)
(define-key elfeed-search-mode-map (kbd "B") 'elfeed-search-eww-open)

Comparing my present elfeed setup with my former Newsboat setup, one thing that is much nicer with these scripts and elfeed is that I don't have to use an external program for podcasts. Newsboat comes with podboat which is intended for use as a podcatcher after you have qued up the content within Newsboat. That process always felt cumbersome and I actually didn't use it because of that. With elfeed and a few scripts, I have all kinds of feeds within the one reader and use a few different keyboard shortcuts to get everything done that I want. Another nice thing with elfeed is its search functionality which is very powerful.

My Emacs journey is still in its infancy, but the more I delve into Emacs, the more I like it. It's powerful, personal and pleasant. Emacs extends the hackability of GNU/Linux further by allowing you to tweak not only your DE or WM through configuration and shell scripts, but also the program you do most of your tasks inside. Integrating more functionality into Emacs means less friction and context switching between different tasks. Thus far, I have only integrated RSS reader, email, pdf document creation (org mode with latex export to pdf), blogging (org mode and org-static-blog), some web browsing (Firefox is still my default browser, but I use eww more and more), note-taking in org mode (I used to use vim and markdown) and of course general text-editing.

It's interesting how much faster for instance navigating around my emails is in mu4e within Emacs than in Thunderbird which was my previous email program. I think the reason is that Emacs is both text and keybord-centric (while also allowing for mouse use if you are so inclined). Elfeed has also become more useful than Newsboat used to be for me since I now also use it for podcasts. The hackability of Emacs means you can add functionality you want or customize things to your own preferences easily. Emacs also uses less system resources than other programs while doing more. Fewer resources means less power use and longer battery life on laptops. You can save money and possibly also CO2 emissions if your electicity is produced in environmentally unfriendly ways.

I see Emacs as the ultimate step in my gradual move towards less resource usage for my computing that started when I switched from Mac OS X to GNU/Linux in 2011, moved to a light-weight desktop environment (LXDE and later LXQt), then to even lighter weight window managers, gradually switched some GUI programs with terminal programs and scripts and then in the end the gradual integration of many tasks into Emacs. (I did this mainly out of curiosity, but I have reaped other rewards like less resource usage and more freedom as well.) If you see Emacs as only a text editor, then it is more resource hungry than vim (but less than VSCode), but if you see it as what it is: an integrated, hackable computing environment, then it is less resource hungry than the combination of programs you would use to do the same tasks. It is also the ultimate expression of the FSF's ideal of empowering users through the use of free software. I am definitively going to delve deeper into Emacs in the months to come.

27 aug. 2022

Vim vs Emacs for fast text editing

vimvsemacs.jpg

Introduction

I used vim for 2 years and got it into my muscle memory before my Emacs curiosity led me to try out GNU Emacs in the spring of 2022. Many people say vim is the faster text editor, but Emacs is wonderfully extensible. After having used both, I don't think vim is faster than Emacs, so I am going to show how many consecutive key presses you need to accomplish some common tasks in both and compare. Of course, you can use evil-mode in Emacs and edit text the vim way, but I am comparing the usual non-evil default keybindings of Emacs with the defaults in vim. There is also the common halftruth about crazy key chords in Emacs contra simple one-key presses in vim. This is true for many workflows, but not so much for actual text editing. For text editing, the keyboard shortcuts in Emacs are usually just a modifier key plus an alphanumeric key.

I believe that pressing two keys at once takes the same amount of time as pressing one key. I call both "a keypress". On the other hand, pressing three keys consecutively takes three times longer than pressing three keys at once because you have to depress one key, lift up your finger, then depress the next key, lift your finger and then depress the next key and lift your finger. Therefore the actual speed of editing is determined by the number of consecutive keypresses to get something done, not the total number of keys depressed. As an example, I often press C-c C-, s (Ctrl-C Ctrl-, s) to insert a code block in org mode which is three consecutive key presses and a total of four keys (I hold Ctrl down from the time I start pressing c until I have finished pressing ,). This could have been faster if it involved fewer consecutive keypresses even with the same amount of totalt keys, like for instance the keypress C-M-S-, (Ctrl-Alt-Shift-,) which is just one keypress, but also four total keys. My point is that when thinking about the speed of editing, it is the number of consecutive keypresses that matter, not how many keys you press at once (although fewer is less akward for the hand).

In this blog post, I will use Emacs symbols for keybindings in Emacs where C = Ctrl, M = Meta (Alt or press and release Esc), S = Shift and s = super (Windows/Tux/Purism/Apple Commmand Key/…). Emacs keybindings are generally written with a dash when pressed together and with a space in between when consecutive, for instance M-b C-p means Alt and b pressed at the same time and then Ctrl and p pressed at the same time. When the same modifier key is used for two consecutive key presses, it does not have to be released like the example above with C-c C-, s shows. When writing about Vim, I will use Esc for Escape and use no space between consecutive keypresses which is the usual vim way, for exampel 2gj for the three consecutive keypresses 2, g and j. All other glyphs just represent themselves.

Comparison of keypresses for common editing tasks

Before starting to write anything in vim, you have to press i (or a or o etc). In Emacs, you just start writing. That's one keypress for vim and zero for Emacs. After you have written a sentence, maybe you want to move back and do an edit. Let's say you want to move to the start of the sentence you just wrote and add something in front of the first sentence. In vim you would press Esc to get to normal mode and then 0 to move to the start of the line (not necessarily the line you see on screen, but the start of the chunk of text since the last newline character) and then you would have to press i. In Emacs, you would press C-a (or M-a if the sentence is longer than one visual line) and start to write. In vim, you would need three consecutive key presses and in Emacs one before you started to write your new first sentence. After you have written your new sentence, maybe you want to go to the end of your paragraph and add something. In vim, you would press Esc, then A and then start to write. In Emacs, you would press C-} and then start to write. Again, vim has two consecutive keypresses and Emacs has one before writing.

Maybe we want to move two visual lines up and correct the misspelling of the word "icnonsequently" next. The word is two visual lines up, but starts four columns (four letters) to the left of where we are now. In vim, you would press Esc to get to normal mode, then 2gk (that is not one keypress, but three consecutive key presses) and then 3h (two key presses), then d, l, i and c, which is 1 + 3 + 2 + 1 + 1 + 1 + 1 = 10 consecutive key presses. In Emacs, you would press C-2 C-p (or C-p C-p) (two consecutive key presses to move up two visual lines since Emacs works on those), then C-2 C-b, then C-t (to use the function transpose chars with the cursor at the third letter), ie 5 consecutive key presses.

I could probably think of more examples, but the point is that for most edits, Emacs demands fewer consecutive key presses than vim. You can check out Emacs Rocks' episode 3 and 4 where Emacs is faster than vim for a couple of Vim golf tasks. Protesilaos Stavrou has also made a video where he shows off Emacs Macros for solving Vim Golf tasks. I think most of these are faster than vim as well. There are probably more examples floating around the internet if you care to find them.

How can vim be slower than Emacs? Everyone think it is the opposite…

The reason why we get more consecutive key presses and spend more time to get from one point to another and start writing in vim is because of the modal editing. Since we constantly have to hit Esc to get to normal mode before moving around and then hit a, o, i, r, c, A, O, C or I before actually getting to start typing our text, we generally need two or at least one (when combining movement and getting into insert mode like with A) more consecutive keypresses for moving around and starting to write in vim than in Emacs. There are also more functions in Emacs for editing text, many of which are bound to simple key combos like the function transpose-chars that we used above which further saves keypresses compared to manually deleting a character, moving and then adding the same carachter one letter later in the word. Even if you count the total number of keys depressed and disregard that it is faster to press two keys at once than to press the same two keys after each other, Emacs usually ends up with fewer total number of keys pressed for doing the same edits.

Modal editing, as shown above, is slower since you have to go in and out of modes. In addition, it is very unlike any workflow most of us have ever used before, which means that it takes more time to learn text editing in vim than to learn text editing in Emacs. As someone who has spent time learning both vim and Emacs, I found it a much steeper learning curve to learn vim for text editing. Emacs can also do everything else, so you can continue to learn Emacs after your muscle memory has adjusted to its text editing workflow and that is the reason why many people think Emacs is hard to learn, but for text editing, it is actually much easier to learn than vim since the way you edit text in Emacs is less weird.

Both vim and Emacs have good tutorials that you should spend some time with when trying them out for the first time, but for vim, I felt like I had to go back to the tutorial a lot of times before I really mastered the concepts of modal editing. When I finally made my own vim cheat sheet for my Norwegian keyboard layout and hung it on the wall underneath my screen, I finally started to get its keyboard shortcuts into my muscle memory. (I published that cheat sheet here, but realized I did not actually have the right to base my sheet on the model I used since it was not published under a free culture license, so I had to remove it.) With Emacs, I felt that the text editing keyboard shortcuts were more intuitive and easier to learn and remember, although I have made a cheat sheet that I plan to laminate soon and hang where my vim cheat sheet used to hang before.

Ok, so Emacs is faster for text editing, but what about…

Editing remotely

Emacs has built in functionality called TRAMP which lets you edit files on remote servers through SSH from the comfort of your own, well-configured Emacs. If you use Vim on the remote server through SSH, you get the configuration of vim from the server which is probably vanilla vim which might feel foreign if you have spent some time editing your vim configuration. Or you could spend time transferring your config over to the server. There is nothing stopping you from running terminal Emacs from the remote server through SSH if you absolutely must, but you get the same disadvantage as with a remote vim that you do not get to use your own configuration. TRAMP is the elegant solution to this problem.

Lightweigh footprint

Vim is usually used in the terminal (even though gVim exists) and Emacs is usually used as an X program (with Wayland support probably landing in version 29). This makes typical vim more minimal than typical Emacs. This is true. However, Emacs works perfectly well in a terminal as well. Both vim and Emacs started out as terminal line editors (ed and Teco) in the 1970s that over time morphed into the programs we know and love today, so even if they both have GTK X11 variants, the terminal is where they both grew up. You loose the ability to have different fonts in different modes and you loose the ability to show pictures inside buffers, but othwerise, Emacs runs really well in a terminal. The X clipboard needs a package for integration into Emacs if you use it in the terminal (just like vim's registers do not correspond with the X clipboard without some configuration except if you have installed gVim and use terminal vim based on it) or you could use C-S-c and C-S-v which most terminals use today to copy and paste (as in vim) if you don't mind changing your habits. If you use many custom keybindings including C-m or C-i, you probably want to rebind those to something else since they have special meaning in a terminal. Or you could configure your terminal to treat those keys differently.

All that being said, Emacs is heavier than vim because it includes a lot of built in functionality that vim does not have. This might be good or it might be bad depending on your point of view. I recently spent some time in Emacs on the tty of my Raspberry Pi 3 B+ and surfed the web with Emacs' built in eww browser to check something in the Debian Wiki quickly before continuing to configure my minimal Debian system. I checked "free -m" from Emacs' ANSI term (one of the many built in terminal emulators inside Emacs) and I used 128 MB of RAM with three buffers open: eww, ANSI term and a scratch buffer. You could use W3M and vim alternating to achieve the same, but I think the few extra MBs of RAM and SSD space Emacs takes is worth it to get to do it all within one program (even when used from a tty).

Emacs might be fast at editing, but it starts slowly

Emacs can be slow to start if you have a lot of stuff in your config. The recommended way to avoid this (both for terminal use and graphical use) is to use Emacs as a server that starts up with either a systemd unit or other init script or you can start it with your Window Manager or Desktop Environment at startup. Whenever you then want to use Emacs, you should use "emacsclient" to open a window to the already running Emacs server process. This makes startup of your Emacs window ("frame" in Emacs terminology) or terminal window very fast. I have bound "emacsclient -c -n" to Super+F6 in my Sway config to fast get a new window with Emacs whenever I need one.

Ergonomics

This is where vim shines, especially if you rebind Esc to Caps Lock which many people recommend for vim use. Modal editing means that you can do all your edits with keyboard shortcuts that are generally just Esc to get to Normal mode and then one alphanumeric key for each command, unlike in Emacs where you have to use one or more modifiers plus an alphanumeric key to get the same thing done. In text editing, the key chords are simple in Emacs, but for other workflows, there are some crazy keychords. When you learn that you can keep Ctrl depressed if you have two consecutive keypresses which contain it, that helps. Over time, most key chords you use often become muscle memory and if you want to rebind crazy keybindings you use often, that is easy to do. Many recommend rebinding Ctrl to Caps Lock for Emacs use since then you have ctrl in a more natural position for you left pinky. I think ergonomics is the real reason why many prefer vim. It is not faster to press more consecutive keypresses even if there are fewer keys in each, but it is more ergonomic. It is probably also the reason some Emacs users use evil mode and that it exists in the first place. Since Emacs is an Elisp interpreter, you can do things like that, but using Emacs keybindings in vim is not possible since vim isn't as hackable as Emacs.

Unix philosophy

Emacs does one thing well and that is to interpret Emacs Lisp. It does not matter if you edit text, chat on IRC, read and reply to email or look at PDFs while taking notes in Org Mode, it is all done by executing Emacs Lisp. Many Emacs users use it as a program that integrates many tasks they do into one cohesive workflow. Even if Emacs can become all-encompassing, it does not have to. You can just use it as a text editor if you want. Today, vim both interprets VimScript and edits text and NeoVim does the same plus interprets Lua and is embeddable. Emacs just interprets Emacs Lisp. Maybe you need a bit of mental gymnastics to get any of these programs to fit the "a small program that does one thing well" philosophy?

Conclusion

The myth that Emacs is good at anything except text editing is a myth, not a fact. It is a slightly faster text editor than vim and it is much easier to learn to edit text in because you do not have to grasp the concept of modal editing. Even so, how many key presses you need to get things done and how much time it takes might be less important to you than other factors when you choose your text editor, especially since most time is probably spent thinking. How inspired you feel by the software might be more important to you than the speed of editing. Maybe you prefer to separate different functionality into different programs and configure all of them to use vim binding or maybe you like to integrate them all into a hypermoldable, super-hackable Emacs Lisp interpreter. Or maybe it is important for you to use the same software as your colleagues, friends or fellow students to be able to share their workflow tweaks and take part in a shared culture?

I think both (Neo)vim and Emacs are good choices for investing some time into learning since they both have strong communities that will make sure they will be around for fitfy years more (unlike some editors, both FOSS and non-free, that are developed by companies or individuals without communtiy participation and may be abondoned at any time, like Atom exemplified recently). Both editors demand a bit of configuration which is a slightly different approach than many of the newer editors that are more ready out of the box experiences, but might not be as flexible to adjust to your workflow (as opposed to you adjusting to theirs). In the end, you choose the tools that work the best for you. Just don't lie and say you use vim because it is faster when you haven't even given Emacs the chance to convince you otherwise.

Other posts
All blog content is licensed under the Creative Commons Attribution-ShareAlike. Produced with GNU Emacs, Org Mode and org-static-blog on GNU/Linux.