I have been a GNU/Linux power user for about 6 years now. Most of work is done in the terminal and I have used all the LARPy suckless or suckless-adjacent software. It’s both a preference and a hobby.

Likewise I fell for the meme takes of this or that software being bloat, most notably emacs and systemd. I’ll save the latter for another poast, stay tuned avid reader.

Whilst I won’t directly address whether emacs is bloat or not, I will address the fact that most terminal/suckless cosplayers - like myself - are actually be better suited using emacs over the Luke Smith starter pack.

In general, I think most terminal or power users care less about whether the program is strictly suckless - meaning lacking features but having some way to be extended via patching or separate programs - and more about the functionality and quality of the software. Whether something is suckless or bloat is ultimately a goal-posted opinion where there goal-posts are free to move. Vim is bloat, use vi. Vi is bloat, use ex. Ex is bloat, use ed. Ed is bloat, use cat, sed, and awk. Sed and awk are bloat, just don’t make mistakes.

There’s no real standard, except that in the end software quality will play the biggest role in our decision to use one thing or the other. Vim is full of features that are inspired from heckin-bloated emacs, but because it is so nice to use and the features can stay out of the way, nobody cares. I’ll save the bloat rant for another post.

Key Features of Emacs

1. Unified “Terminal” System
2. Daemon/Client - tmux not required. Quitting the editor does not kill the buffer, unlike vim.
3. Documentation (info pages) and help system.

I’ll cover points 1 and 2 in this post, and save the documentation for another post.

Inconsistent System Experience

One of the problems I have after falling for the minimal software meme is remembering and deconflicting all the terminal bindings. Bash and other shells use the readline library with emacs bindings by default (I prefer this over vi even before using emacs), tmux has its own bindings mostly using ctrl-b (this conflicts with readline/emacs), weechat has its own bindings using alt/ctrl, vim has its bindings for splits, profanity, newsboat, lynx, etc etc. Plus your window manager keybindings. You really have to think about all of those and be strategic about how you lay out the bindings for your entire system.

Regardless of which window manager or DE (LXDE if anything) I am running, I use sxhkd to launch all programs. The sxhkdrc file is my master-list of all keybindings on my system. Everything is arranged by prefix keys, and I keep everything used by various programs commented out so I don’t override them with sxhkd bindings. For most programs, I think there’s a lot of wisdom in sticking with default keybindings because chances are they won’t conflict as much with other terminal/program bindings.

Consistent and Unified System UI and Experience

Emacs simplifies a ton of this. Everything in Emacs is an Emacs buffer, so Emacs keybindings - whether those keybindings are emacs, vi/evil, meow, or some other editing system - work on every program. There’s no mucking around trying to get scroll support in a terminal or program, or a way to copy text into your clipboard, or having different keybindings for vim splits and tmux splits. It’s all the same.

Likewise because everything is run in an Emacs buffer, all editor commands perform the same operation whether it’s a text file, web browser, irc client, or email message. You can create functions to manipulate text in one type of file/buffer that will work on other buffers. Tsoding had a recent video on the usefulness of emacs, and one of the key points was that emacs unifies programs that were never designed to work together. So trve, king.

Here’s an extremely useful but simple example: scanning for urls. Luke Smith’s st has series of combined patches that allow you scan the terminal window for urls, pipe them to dmenu, and then launch the selected url in the default system browser. Super handy. It doesn’t necessarily work with all terminal programs, though.

But in emacs, this is a very easy function to write that can be easily extended. It’s all done in about 20 lines. I’ve bound this function to C-c g g (for go). A minibuffer pops up with a list of all url’s in the buffer, similar to st/dmenu. I select the url I’m looking for with C-n/C-p, hit enter, and the link opens in my default browser. If I press C-c g e, it opens in eww (emacs built-in browser). If I press C-c g c, the same base function is used to show all urls in a minibuffer, hitting return just copies the url to clipboard instead of opening in a browser. No scrolling through the articles or text (which is also easier than most apps because of unified emacs keybindings). No highlighting and pressing a copy keybinding. I can use that url copy function in any buffer - irc, webpage, text file. It’s all the same in Emacs.

These functions scan for urls in the entire buffer. But what if I just want to select the urls that are shown on screen? Easy modification. No patching sauce code or anything like that.

Programs I’ve replaced with Emacs

Most of these are very easy to set up. Elfeed is definitely the exception if you’re coming from newsboat, and I haven’t taken the time to completely replicate my newsboat setup which used mpv for podcasts and youtube vidyo, plus has a number of browser keybindings so I can open articles in text browsers (assuming a full-feed isn’t provided) and graphical browsers. So for now I am still mostly using newsboat.

Which of these are “killer apps”? For my uses, I’m not sure I would call any of them killer apps on their own, though I don’t even view org-mode as a killer emacs app. I can survive just fine without them.

They become killer apps by virtue of being a part of emacs.

I’ve never been a huge terminal file-manager user, cli has always just worked. Dired on its own is a good file manager, no better or worse than vifm, ranger, yazi, lf - they’re all kind of the same in my book. Where it is extremely powerful is that it integrates with everything else in emacs, including TRAMP which is EXTREMELY useful when editing on remote machines. Not going to cover it here in detail, but TRAMP allows you to edit remote files in your current emacs environment. Before using emacs I had in my head that in order to use emacs on a server, you needed to install emacs on the server (which could add a bit of gbs). Not the case.

My favourite dired feature is the ability to open two dired buffers in a split window, and any command done in one buffer is assumed to end in the other buffer. I.e. if I copy a file/files or make symbolic link/links in one dired buffer, emacs assumes the target is the other dired buffer. Very handy. You can also change the target directory if that isn’t the case.

erc is the best irc client I’ve used.

ement is a very good matrix client, not that the competition is great.

jabber.el has seen recent improvements, it works fine.

magit is the closest to a killer app on its own, not for me, but for anyone who heavily uses git. Your git workflow becomes extremely fast with magit and the ability to quickly do partial commits is a huge qol feature.

Key Difference: GUI vs terminal features

For most of these programs, a big difference is that when run as a graphical emacs session (normally the case), they are gui programs. They do not have the limitations of terminal text. Fonts can vary in size and are not limited to monospace. Images render just fine.

So whilst mu4e and eww are good programs, they are much better than terminal variants because they render text and images as designed. So with emacs you get the best of both worlds: minimal and hackable terminal interface with gui quality of life features.

Edit: Note on Documentation

Whilst I will cover emacs documentation in another post, it’s a key feature to mention here because all the features and keybindings for a given program are easily accessible with emacs built-in documentation, usually with simple popup-menus. Can’t remember how to do a certain operation in dired? C-h m shows you all of the dired keybindings and mode information. Curious what a keybinding does? C-h k will show you what the next keybinding you press does. Want to see all your bindings tied to C-c? which-key makes that a breeze in the minibuffer. Recently added help-quick-toggle with C-h C-q is probably the easiest of the bunch I’ve listed.

No man pages, no creating keybinding tables to track everything.

Conclusion

The suckless/terminal mindset is aimed at simplicity. Use simple programs that generally do one thing well, and stay in the terminal to avoid bloat, distraction, slow, feature creep, etc. Making all this happen can be a complex process though.

In my opinion, you’re better of accepting the “bloat” and “complexity” of emacs - I put complexity in quotes because emacs itself is actually a simple program - in order for simplicity of configuration, less mental taxation, and easier/better extensibility. Admittedly this will come at the expense of an extra gb or two of storage if you can spare it.

We all have fallen for the suckless LARP, why not fall for the emacs meme as well?

Nevertheless I wanted my custom bindings to be “mode” agnostic, so that ruled out using general.el and also using SPC as a leader key (since the non-modal default bindings need to insert a space with SPC). I tried Alt-SPC for a while instead, but that was surprisingly awkward even though it can be done with either hand, one hand, or even just the thumb if angled correctly. I decided to just embrace conventional emacs wisdom and rewrite my custom keybindings with C-c.

On my first read-through of Mastering Emacs, I thought some of the emacs navigation bindings were just ridiculous; the shear volume of bindings with no seeming rhyme or reason seemed absurd. After forcing myself to learn them, I realize the navigation bindings are actually surprisingly consistent - it’s the same pattern across windows, frames, and tabs. And C-c for custom bindings has been just fine. It was with this in mind that I thought: maybe I’m just misunderstanding the emacs editor keybindings as well?

My first step was to create my emacs keybindings that I could access in insert-mode (called insert state in evil). Not really necessary as you can locally toggle evil-mode with C-z, but this at least got me to start using things like M-d or C-k when I was too lazy to hit the ESC key to get back into normal mode. This was fine, but it wasn’t enough to seriously learn and use them.

So after a couple minutes of consideration and somewhat on a whim, I decided to rip off the bandaid and switch away from using evil-mode in gnu emacs. Here are some of my reasons for doing so:

Abbreviated and impromptu list of reasons to not use evil mode:

1. Curiosity.
2. Improve my bash default keybinding proficiency.
3. Not be completely retarded when my init.el fails to fully load or cannot load at all.
4. Cut down on emacs packages and abstractions.
5. Most importantly: experience emacs packages as the developers intended.

I really want to focus mostly on the last one because that is my primary motivation. It was during my research of elfeed that I realized evil-mode and specifically evil-collection do quite a bit of violence to the original keybindings from the author. By now I knew that evil-collection made changes on most packages - e.g. dired - but for the most part they’re pretty sane and retain most of the original bindings. This was not the case with elfeed, and reading documentation proved to be somewhat a moot point as basically everything had been changed to line up with a vim-style workflow. It made me wonder - what other aspects of emacs are being substantially changed because of evil and evil-collection? Am I losing out on some gucci emacs feature because of evil-mode?

Concerns

I have three major concerns with switching away from vim/evil keybindings:

1. Inability to rewire my brain away from vim habits.
2. Missing out on features I’ve come to love (e.g. visual-mode commands and vim’s search/replace mechanism).
3. Finger strain - the famed emacs-pinky.

For the first one I figure there’s only one way around - practice. I took a look at god-mode and meow-mode to see if there was a way to “have my cake and eat it too” so to speak, but I realized these would be similar to vim and at the same time different enough that I am unlearning and replacing vimisms with vim-like alternatives rather than learning a whole new set of bindings. Meow would still require me to have some proficiency with emacs bindings for the non-text buffers. As I went through the emacs tutor again, I came to the conclusion that emacs and vim bindings are probably different enough that I should be able to compartmentalize them fairly well. The same cannot be said of vim and meow as I would chose one to the detriment of the other.

For the second one, this is more of a concern with having to learn new ways of doing the same things. Considering emacs is a lisp-interpreter ultimately and isn’t bound by the same restrictions as vim or any other program, I’m confident solutions for my favorite vim features exists in emacs - it just won’t start with a colon or some other vim key.

Regarding the last one, I figure this is something I’ll be able to learn soon enough to prevent any issues should they arise. However, I heard from one of Prot’s vids that the best hack for emacs bindings is learning proper typing habits using both the left and right hand. This is something I had been working on anyway; C-c as your leader key gives you a ton of practice breaking away from just using the left hand, for example. With caps lock remapped to control, I’ve had very little issue using both hands for CTRL and ALT key operations, even when those keybindings involve switching hands in the middle of a key combination. As an added bonus I am no longer engaging caps-lock and doing all kinds of unintended stuff.

So if anything I look at this as a really good opportunity to perfect my typing The next step will be split-keyboards, but that’s a level of autism I shouldn’t approach lest I go down another potentially expensive rabbit hole.

One Week Review

So far I have no real complaints not using vim/evil mode. It hasn’t taken long to get familiarized with the default keybindings for various programs; really that aspect of emacs is no different, just using b/n/p/f instead of h/j/k/l. One of my main fears was that I would always need two-hands to do any kind of scrolling or navigating, but this really isn’t the case. In almost all buffers, “n” and “p” will move up/down without the control key, so one-handed browsing has not really been an issue.

I’ve stopped mashing ESC all the time like I am accustomed to.

Learning the emacs bindings is surprisingly easy because they’re largely pneumonic-based. Even in programs like dired: up-directory is ^, a symbol that looks like an up arrow, for example. Not always the easiest to reach, but easy to remember.

Editable buffers took about a day to knock off some rust iron oxide, but it’s been fine. Slower for sure, but not drastically. I suppose akin to the non-soystemd inits booting quicker - it is true dinit and runit boot quicker, but not to the extent that it drastically changes your computing experience. A lifetime of booting with dinit over soystemd will save tens of minutes. Likewise I think the extra time it takes with emacs bindings is a drop in the bucket, at least for my uses. Completely different story for programmers.

I can already tell emacs bindings have some advantages over vim - probably fewer compared with vim’s advantages but for the right person the advantages of emacs bindings could be substantial. For writing prose I can see how emacs bindings are really nice - there are a ton of sentence/paragraph oriented operations that don’t have parallels in vim (and don’t need to tbh considering the target audience of sysadmins and programmers). Plus transposition of characters and words.

I think the biggest strength of emacs bindings (so far) is the kill ring. Yes, there’s a way you can access it in evil, but you have to customize that yourself. And this is a feature that carries over to bash which does not have an equivalent in readline vi-mode (to my knowledge).

Long-Term Prediction

I’m going to give it some time, probably close to a year to get an honest review, but if I had to guess I am most likely done with evil/vim bindings in emacs. I’d also like to toy with the built-in viper-mode which emulates vi-bindings. My vimrc is split up between vi-compatible options and vim-specific stuff, so I’m already very familiar with the vi limitations and honestly, it doesn’t bother me much. But that probably will not be a long-term solution if viper-mode affects more than just the editor. I can already tell that emacs “feels” better integrated and more consistent with the default bindings.

So if you’re like me and seemingly tied to vim-bindings, try breaking out of your comfort zone a bit and cracking open the emacs tutor with C-h t. Emacs tutor is extremely useful even beyond the editor bindings, but it’s unfortunately kind of useless if done in evil mode.

You might be surprised.

Prior to Emacs

Prior to using Emacs I was (and still am) a vim user, preferring simple configs and using as much of the built-in features of vim as possible. See my first blog post for more info. I bought in to a lot of the meme takes that emacs is bloated and contrary to the Unix philosophy, suckless dot org type stuff. In hindsight this is really just saying “Emacs is hard, I don’t understand it yet, so I’m going to have a reason to justify not using it.” I’ll save the bloat rant for another post.

Like most things unknown, I never felt a need to use Emacs - everything I needed was found in vim and a slew of cli tools. So I thought.

Need to Learn Lisp

In early 2022 I started a new job which involved a lot of design work on AutoCAD. AutoCAD is a piece of software I have a love/hate relationship with: I love it because I have to use it and have so for the majority of my engineering training and career. It does what it needs to well enough, and is pretty extensible for such a monstrosity of proprietary software. I can say a whole lot more negative about it, and I already said I’d save the blot rant for another post.

AutoCAD is a relatively old piece of software, so old that it uses Lisp for scripting. Like all Lisps, AutoCAD Lisp is its own flavor but shares a lot of similarities with Common Lisp. Prior to this job I never had a need to use scripting within AutoCAD, so I took the opportunity to learn Lisp from one of the handful of popular Lisp projects: GNU Emacs.

Starting with Doom Emacs

I took the route most vim users probably do and start with a pre-configured Emacs rice, and for me that was Doom Emacs. It was a way to get my feet wet and see what Emacs is capable of before going all-in on a vanilla config. With projects like Doom and Spacemacs you get a possible end result for inspiration, perspective, and motivation, because you sure as hell are getting none of that when launching vanilla emacs for the first time. Similar to using a pre-riced window manager like those which used to ship with Arco Linux, or any of the many Arch Linux-based “distros” which are simply just bloated wm rices (Omarchy).

Even though I no longer use Doom and don’t recommend using pre-packaged configs for long term use, I still think it’s a good place to start if you’re just curious and don’t want to dedicate too much time or effort to software you may not actually like. Doom and Spacemacs give a very pleasant first impression, which was not the case when I first opened vanilla emacs out of curiosity when I was brand-new to Linux. And those first impressions are often what will make or break your opinion of the software - the same reason we almost always recommend Linux Mint to new users.

Leaving Doom

Doom is a very opinionated Emacs framework. The mods are impressive and its speed is something to behold considering all the bloat (it is actually bloated). As a newb I found it very difficult to figure out exactly what was going on under the hood; it felt very far removed from the core system and I felt like a lot of the Emacs guidance in older posts or references simply didn’t apply. Emacs is different enough as it is, and I think that’s the main reason people write off Emacs as bloated or dumb or inferior: it is different and hard when coming from anything else. To an extent Doom adds to that complexity, almost like added another OS-layer onto a program that is jokingly (but accurately) called an OS running on an OS.

Overall Doom Emacs gave me a very positive opinion on Emacs, but I knew I would be on a vanilla config in short time.

Building a Vanilla Config

After some time I decided to move to a vanilla emacs configuration. SystemCrafters and Prot were really helpful. My fairly lean ~1500 line init.el had a lot of the features you found in the wild at that time - use-package, evil & evil-collection, general, which-key, counsel, ivy, ivy-rich, corfu, etc. It relied pretty heavily on outside packages but was not nearly the beast that is Doom. And it was set and forget for about a year of primary use.

I stopped using Emacs

I stopped using Emacs because I found myself using my personal computer less and less. Other interests occupied my spare time; linux hacking became dull. I’ll go on several-month to year+ “binges” on whatever interests me the most. At that time I was making a lot of improvements to my house, so a lot of time was spent playing with power tools and clearing out woods. And a ton of biking.

If I was using an editor, it was vim, simply because I wasn’t doing anything more than tweaking a few shell scripts.

Return to Emacs

Alas last fall my interest in linux was renewed through self-hosting and making a homelab, as cringe as that word is. It is a level of fun I hadn’t tapped into and a side of linux (larping as a sysadmin) I hadn’t done much of before. And so it was only a matter of time before I jumped back on the Emacs train, even if just out of curiousity.

Fast foward to January, 2026. I haven’t touched Emacs in over 2 years, probably closer to 3. I see and consoom a bit of new emacs content on yt, some new guys in the game, joined some chats with a number of emacs users, and decide to fire her up again. After a couple minutes of package updating, to my surprise it launches just as I remembered it. Had to refresh myself on some of the major keybindings, but that came back pretty quick. Emacs is great because M-x (alt-x) can be used to launch anything, and C-h can be used to quickly access help files. So when you can’t remember what to do it doesn’t take much effort to figure out, especially if using some kind of matching/completion system in the minibuffer (recommended). I take the same approach with vim - learn the commands over the keybindings.

As I re-write my config and experiment more with Emacs, I’ll post here to document what I’ve done without the need for a bloated literate config, as well as some spicy Emacs takes. That way any of you Emacs-curious readers or Doom Emacs enjoyers can learn from my mistakes experiences and be on your way to a diy config.

If you’re curious about Emacs, give it a try. It’s fun - that’s the only reason you need.

Around 2020 (from what I can remember) things started to change. Lua was becoming a first-class citizen in neovim, various projects which resembled Emacs distributions were popping up, lua plugins were becoming more popular and optimized, and other things to distinguish neovim from vim. Whilst I always tried to minimize the number of plugins I used in vim - mainly for speed since was/am using old laptops as GNU/Linux enjoyers are wont to do - in neovim it became increasingly irrelevent because of how snappy “bloated” lua configs could be. Neovim could easily become a full-blown terminal IDE without any effect on performance, making it loads faster than its IDE competition, and better by virtue of being vim vs a compatibility layer like in vscodium.

With that in mind, why do I continue to use paleo-vim?

Use case

Let’s first look at my vim use case. Professionally I am not a programmer (as much as I might cosplay with LISP at work). I use vim primarily for what it is: a text editor. I use vim to edit files on my desktop and the many servers that I use. I need to have a simple config that I can quickly copy over to a server when needed, or if not possible one that I can generate on my own. Vimrc in its default location (~/.vimrc) is quickest to transfer over to another server. Whilst this could easily be located in ~/.vim/vimrc, using scp this introduces a bit more complexity: removing the ~/.vimrc file if it exists, checking for the ~/.vim directory and creating it if not present, and then copying vimrc to the ~/.vim directory. Easy to script, but often I don’t want to hassle with that. The same logic applies for neovim just with ~/.config/init.vim. Many people make a big deal about crowding the home directory with dotfiles, and that’s something my tism really doesn’t care about. Perhaps more on that in another post.

Plugins

I have only a handful of plugins and each are lazy-loaded, meaning they don’t load until I call the plugin’s function. Currently [at this time] I am using vimwiki, vifm, and fzf. Generally I never use any of these plugins, and fzf comes in handly on occation when I’m looking for specific files for libraries in /var. I only use default colorschemes, and thanks to neovim-inspired updates there are some really good default colorschemes - retrobox gang rise up. My vimrc checks if the plugins directory exists before loading pluins - which is basically never on servers - so my vimrc is itempotent. Additionally I unfortunately use Windowns at work, so my vimrc has conditionals for Windowns and GNU/Linux/BSD. All this is possible on neovim of course, but it gets back to a more fundamental issue: why change an editor if nothing will change what I do with said editor?

Vimscript

I like vimscript. I use it all the time for ad-hoc commands within vim. Does it suck as a plugin language? Probably. Do I like lua? Yeah, I do like lua. It’s a smart choice for what neovim aims to achieve. I have used it in other programs. I don’t have strong feelings towards vim9script because I’ve never felt a need to deviate from paleo-vimscript. Hats off to neovim for keeping backwards compatibility with vimscript and also making compatability for vim9. Regardless of what you think of vimscript, you need to now some of it - at least ad-hoc set commands.

Gill Bates

Speaking of Windowns, I’ve found gvim works better than neovim. Despite vimrc having a different name in Windows (_vimrc), I have a macro that copies .vimrc and renames to _vimrc. Neovim on Windowns only works in the terminal, and short of alacritty the windows terminals aren’t great. I haven’t tried neovim on Windowns in about several years, so this has probably changed as a lot has happened with Neovim since.

Contrarian

As much as I try to fight it, I can be a contrarian. In 2026 using paleo-vim is the contrarian thing to do. When Bram passed (RIP) I wasn’t sure where the project would go, but fortunately it has been more or less business as usual since. This contrarian spirit extends to much of my computing setup: openrc, xorg / xlibre, Emacs, vanilla GNU/Emacs, C vs rust, etc, and in plenty of other areas in my life.

Emacs is Neovim but better

Rather than ricing out neovim to be an IDE, I prefer just using Emacs. I don’t buy in to the Emacs vs Vim wars because I use each to their strengths. I love the complete operating system Emacs provides and how it eliminates using terminal programs which have similarities, but ultimately are different beasts; they often have keybindings that conflict with one-another, or have some vim-like keybindings but not all of them. This is not a problem in Emacs, and even if it were it would be easy to rectify because of the major/minor mode structure. Weechat, newsboat, tmux, etc, are all wrapped into Emacs.

As a text editor and in the tty, vim absolutely reigns supreme, but Emacs with evil bindings is a passable vim. I have no issues opening a terminal and using vim if needed. But on all my servers vim is a must-have; I would never even think of installing Emacs on my alpine Linux servers just to edit text. More on Emacs in follow-up posts.

Separating Vim from Neovim

All that being said I have a lua-config of neovim on my system. I am a tinkerer and still enjoy the process of learning new things. I have nvchad installed and can open it with a specific config. I don’t regularly use these neovim flavours, but having them completely separate from my vim configs means I can fuxx around with neovim IDEs without touching my .vimrc or creating multiple inits which are called depending on what I want.

Love for the Neovim project

[Again] All that being said I think neovim has been a net-positive. It has completely changed that possibilities with vim, and the project itself has brought improvements to paleo-vim, e.g. improved default colorschemes as mentioned about. Regardless of how you feel about vim9script, it would not have happened had neovim never forked. Neovim has caused a splintering in the projects which I think is a good thing. Old crusty guys like myself stick to vim because of its simplicity and minimalism (relatively speaking; vim is actually bloat compared to nvi which is bloat compared to vi which is bloat compared to ed), and guys who want the plugin-heavy or IDE environment have moved away to a separate project.

This can keep the goals of each project consistent, and vim no longer has to cater to pull requests for features it deems appropriate for neovim. TJ and Prime and other neovim faces also seem like legitimately good guys, and in the past neovim devs have pushed their own improvements to vim when appropriate. Tons of users have discovered the goodness that is vim (in the broad sense) and have moved away from vscode, sublime, gedit (jk nobody uses that trash), or other IDEs/editors because of the hype neovim has on the internet. All good things and I think it shows the long-term (albeit seemingly rare) mutual success that can be possible from project forks.

Emacs is still better though.

Who else uses paleo-vim? Let me know.