Einar's blog
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 where 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 parcitipation 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.

06 aug. 2022

Emacs text-editing cheat sheet

Update august 14th 2022: I moved searching from editing to movement and tidied some explanations.

I have made a text-editing cheat sheet for Emacs. My plan is to print and laminate it and hang it on my wall underneath my screen above my standing desk where I formerly had my vim cheat sheet. I find that quick access at a place I naturally look helps me learn and remember keyboard shortcuts. The more I look at them, the easier they are to remember and the more I use them, the more they become part of my muscle memory.

There are of course a lot more functionality in Emacs with keybindings specific to their particular modes (in Emacs a mode is a group of functionality for a particular workflow or task unlike in vim), but even though Emacs can do anything else as well, it is also a really good text editor. This cheat sheet is only for the text-editing parts of Emacs. There are probably more keyboard commands than I am aware of that should/could have been included. I will probably revise and update this blog post in the future.

I have only used Emacs for a few months by now, but it's text-editing abilities and speed has won me over from vim. I originally just wanted to test Emacs to give it a chance, but I am now convinced I am going to continue to use it. (Neo)vim is also a great text editor, but it is just not as good as Emacs in my opinion. I will write more about why I think this in a future blog post. You are of course free to disagree with me and use whatever text editor you like.

I made this cheat sheet the Emacs way in Org Mode. Underneath, you see a downloadable png of the cheat sheet. The original .org-file is also available for you. Maybe you want a light version instead of the dark png, maybe you want it to be high resolution or maybe you want to include more keychords. As always, my content is licensed as CC BY SA 4.0, so feel free to do whatever you want to the files as long as you attribute me and share your remixes under the same license.

Emacs_text-editing_cheat_sheet.png
04 aug. 2022

I now use org-static-blog to create this blog

I have moved from WordPress to Hugo to nothing and now on to org-static-blog to create this blog. One reason to move to org-static-blog is that I have switched from using vim to using GNU Emacs as my text editor. When I used Hugo, I wrote my blog posts in vim and Hugo made it into a bunch of static pages that I uploaded to my webserver. Hugo has many features, like themes, RSS feeds, tags etc and is very practical to use if you use markdown on a regular basis. Since I was a vim user, my idea was to use markdown for everything and use Hugo for my website and pandoc to convert my .md files into LaTex-styled PDFs, LaTex Beamer presentation PDFs, ODTs and the occasional .docx when needed. I converted most of my older documents to .md and worked like this for a while. Then my Emacs curiosity got the better of me, and this spring, I started dipping my feet into Emacs.

I soon realised the power of Org Mode and that it could replace my former markdown workflow with practical features like automatic tables, lots of easy to use keyboard shortcuts for creating the .org markup syntax and very easy exporting to all the aforementioned formats plus many more. Not to mention that it is also a calendaring and todo-system, that it includes a REPL for any programming language you care for that you can use for literate programming, that it can also be used for journaling, a personal note taking system with reverse-linking etc. Naturally, I have been looking for a way to write my blog posts in Org Mode as well. Many people use Hugo and just convert their .org files to .md files with the emacs package ox-hugo. To me, this seems to be one step more than what I would actually like to do and what is actually necessary. After the war in Ukraine started, I left my website with just a static HTML page, but I have recently wanted to get back into blogging. I had started to work on making a program to make a static site from a bunch of .org files when I discovered the Emacs package org-static-blog that did the same. My plan with my program was to make it first in Bash Shell since I am more familiar with that language and then move it to Elisp for easy integration with Emacs later. Org-static-blog made all that work unneccessary.

Org-static-blog makes a nice index page with a blog-roll of the newest pages, an archive page and an RSS feed. You may also add links to other static pages you would like to include. If you use the tags feature, you can also get RSS feeds for each tag. Personally, I want to just keep things simple for now and have opted out of that feature. To make a new post, you just write an .org file with a title and date and optionally also a description and file tags metadata on the top and then just write your content. Each .org-file becomes a blog post. You can also use org-static-blog-create-new-post to automatically make that document with the correct tags for you which is nice for people like me that have yet to start using metadata heavily in Org files and would enjoy a helping hand with that.

When you are ready to publish your blog, you just run org-static-blog-publish in Emacs, and org-static-blog spits out all the HTML-files you need in your chosen export folder. To make the site look nice, you should make a style.css file that you put into your export folder and link to it in your header as described in the README. There are no themes, but the author links to his own website's Git repo where you can grab his style.css and tweak it to your own liking. As a dark mode lover that also likes to keep things simple, I have opted for a simple black and white look with the occasional light blue for links. The CSS styling is set it and forget it, so after the initial tweak, you are good to go. Just org-static-blog-publish and upload your static files to your website and there you go.

org-static-blog.png

The advantage of using a static site generator over something dynamic is faster load times and easier access to content for non-JavaScript enabled users. Not having unecessary JavaScript running just to show some content that is easily accessible without it also saves power for the site visitors which is good both for the environment and their economy and especially important when Europe is going through an energy crisis caused by Putin's invasion of Ukraine and energy war with Europe.

24 feb. 2022

In support of Ukraine

In support of freedom, democracy and self-determination for Ukraine.

Flag_of_Ukraine.jpg
07 juli 2020

The Non-commercial clause

A month or something ago, I wrote a blog post about changing the license of every cultural product I make. I went with the Creative Commons Attribution Non-Commercial ShareAlike 4.0 International. After writing the blog post, I changed the license of all my pictures on Flickr and the copyright notice on the bottom of this blog.

I have since seen some videos from LibrePlanet, the Free Software foundation's conference and through that been introduced to some new and interresting people and projects that I have checked out online. I don't remember exactly where, but through checking out one of these websites, I came across a a page discussing the Creative Commons Non-Commercial clause. The site states that any Creative Commons license with the Non-Commercial part is non-free and is problematic in a number of ways. The main problems are that it makes the work incompatible with other free works and therefore derivatives and combinations are not possible, it may rule out other basic and beneficial uses (say a charity using the work to earn money), it supports the near-infinite copyright terms (one of the things I want to avoid by using a free culture license on my works) and it is unlikely to increase the potential profit. A share-alike license serves the goal to protect the work from unethical exploitation just as well. There is a long discussion about each of these points.

I had opted to use a ShareAlike license precisely to make certain that my work could not be modified and redistributed as copyrighted by someone else that did the modifications. It also ensure that I am also attributed in any derivative work. It is this ShareAlike part of the license that makes it copylefted, ie, once released under a free license, it cannot be copyrighted again by anyone.

My reasoning for choosing a Non-Commercial License was that I do not want others to reap commercial benefit from my work without having to come to me for a commercial license and thereby making me some money. I then discussed different business models people use to earn money even if their work is licensed as free culture. The implication is that for me to earn money off of my work, I would have to set up some business model around my work. This would be the case even if the work was released to the public with full copyrights without any free culture license.

For most of the business models I can think of, the license for the work does not actually matter. If I were to sell (limited edition) prints of my photographs, the license of the digital file it was printed off of would not matter. Other people could print from that file, but only I can sign my pictures. If I were to set up a patreon or paypal tip button or some other business model where people who appreciate the things I make (whatever the medium) pay me for continuing to make them, it doesn't really matter whether my works are licensed only for non-commercial use or not. If I were to sell a(n) (e)book, it would not matter that the content was also available under a fully free license without the non-commercial part. If I were to make a video course, a workshop, … it would't limit my income from that work if I made the content available under a free license without a non-commercial clause.

The only time the non-commercial part of the license really matters is if my business model is to sue people for using my work commercially to extract some compensation for their use of my work. I would rather spend my time creating things than suing people and companies, and I would rather trust people to get in touch and pay me something if they value what I make, as good people in the free culture community do, instead of spending my time and my money going after people that use my work commercially without contributing back. Maybe I am naive, but I do think that releasing the work for possible sharing and cooperation has a value in itself and makes the work more valuable for the world, not less, even if I might loose a bit of money by not going after people "stealing" my work. If I am able to make a business model that actually works, I would not have to go after people for using my content commercially to earn enough off of my work to make it worth my time.

There is a parrallel between free culture and free software in that many large companies are using and contributing to free software these days, but Amazon and probably many more, are relying on free software projects for their cloud without contributing anything back. Recently, one of the non-SQL-database projects (I cannot remember which) changed their license from a free software license to something restricting commercial use to combat this exploitation by Amazon's Web Services. The result is that their work is now incompatible with Free Software and is either forked or removed from the GNU/Linux distributions and repos where only free software may reside. In effect, the project has made itself less valuable to the community they want to be valuable for, ie. people using free software, for the sake of limiting the commercial exploitation of their work. They have become less relevant and receives less funding from the community as a result of this. Over time, it will definitely harm their brand and Amazon has switched to offering other free software Non-SQL-databases, thereby limiting the project's reach further.

From the example above, it is clear that by licensing work as non-free, one is limiting one's reach within the free software/culture movement, and thereby limiting one's abillity to reach new users willing to fund further work. As Microsoft, IBM, Google, Facebook and Amazon has discovered, the power of collaboration and community is worth more than proprietary products they make by themselves. Not being willing to contribute back to the projects you benefit from when you are one of the largest companies in the world is extremely short-sighted and morally questionable (which many other aspects of these companies' practices also are). Companies and people that want to exploit others for their own benefit will always be here, but for every such company, there are many others that do contribute back to the community.

As a baroque cellist, most of the music I played were made by people making a living creating music in a time long before copyright existed. Most of these great composers did not starve (Monteverdi is the exception) and their work was available for people, less than 70 years after their death, to use, study, modify and distribute, like for instance Mozart's version of Händel's Messiah. Mozart would not be allowed to make that during his lifetime since he died less than 70 years after Händel and the world would have been robbed of a great work of art had Mozart lived under our present copyright laws. Even if the work was licensed as CC BY NC SA, Mozart could not have made his derivative work since it was used commercially.

I am currently not working as an artist, designer, photographer, musician, video maker etc, but when I were, I relied on playing live for (parts of) my income. If I am ever to get back to work as an artist, I will find a businees model that works and continue to use a free culture license so my work can be more valuable to the world since people can modify, share, study and distribute it as they like. Profit can be a motivation factor, but in reality, in most circumstances, there is little to gain except if the business model is to sue people, by using a non-commercial license. I do think it is important to use a ShareAlike license which makes it illegal to change the license of modified versions of the work to ensure that the work and its derivatives stays free cultured. By using a license which demands attribution and is ShareAlike, people also get the chance to find the original creator and possible contribute back if they enjoyed the work or used it for something or simply are curious about who made it in the first place.

To sum up, I am changing my licensing again for my cultural and artistic work from Creative Commons Attribution Non-Commercial ShareAlike 4.0 International (CC BY NC SA) to the fully free culture license Creative Commons Attribution ShareAlike 4.0 Internationl (CC BY SA). It is more in line with my original reasons for licensing my work under a Creative Commons license and it doesn't make it any harder for me, should I ever pursue a carreer in the artst or in culture again, to survive economically. It will make my work relevant and more valuable for the free culture community than if I continued to use a non-commercial license. When it comes to software, my ideal licenses are still the GPL and the AGPL (for server-side software).

Other posts
All blog content is licensed under the Creative Commons Attribution-ShareAlike 4.0.