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.

As I dug through my init.el, I realized there was a ton of functionality that I no longer used, and my inconsistent package syntax was sloppy at best. It was a mash-up of use-package and conventional commands, the result of copypasta from both old and [more] modern solutions found on the internet. For some of the packages I did not remember why they were there or where I originally found inspiration for them. And the videos I watched to help write my init.el are all now 4-5 years old. Surely there have been changes to Emacs.

There have been changes to Emacs.

It turns out Emacs has changed a lot since I last used it (which I believe was the tail end of version 27 when I wrote my config). A ton of features are now built-in: use-package, which-key, fido-mode, project.el, and treesitter to name a few. Many small packages were absorbed or made obsolete by Emacs built-ins (e.g. hide-dotfiles-mode package for dired). Ivy and Counsel still exist, as does the older Helm, but has largely been replaced by Vertico/Orderless among the hoi poloi. These, like many other modern Emacs packages, extend upon built-in functionality rather than reinventing the wheel with separate frameworks like Helm, Ivy, and Counsel.

One of the best Emacs references is the book and blog Mastering Emacs. The author goes through most of the core functionality of Emacs in enough detail to be thorough but not to the point of overwhelming a new user. You’ll be surprised what is already built-in.

Example: Completion

Here’s an example of my thought/discovery process for completion:

Since I want some kind of completion framework, I started with bare-bones ido mode. This is good to know anyway when you inevitably have run a clean config because of an error. Ido mode adds completions for switch-to-buffer and find-file, which is not enough for me. Then I added in the relatively new fido mode which adds completions to the minibuffer with flex matching, and has effectively superseded ido mode (thought ido is still included). I disabled fido mode and enabled only icomplete-vertical-mode. When configured this can be used to get similar functionality to fido-vertical-mode without flex matching. Then I added Vertico, Orderless, Marginalia, and Corfu in order to see what those popular packages give me.

After testing and configuring all of these options, I’ve settled on the built-in fido-vertical-mode because I like flex completions, and configuring in-buffer completions (but not point completions - completions show up in a separate minibuffer) so that completions are shown in a minibuffer but are not selectable (found it a bit clunky). This combo has all the functionality I need from Ivy/Counsel, and the built-in Emacs completion framework is suprisingly customizable. I have no need for the slimmer (relative to Ivy/Counsel) Vertico, Orderless, Marginalia, Corfu, etc, though I do concede they could add value. Corfu does still seem to be the best route for point-completions if you want that, I just found the built-in minibuffer completions to be good enough. The reality is that I’m just so good and tpynig that a rboust cmopltetion framweork is not smoething I need. The lesson in all that is you’d never even know this if you only go through one of the older Emacs video series from SystemCrafters, distrotube, etc.

Another example: themes. The built-in modus themes are on another level. I generally gravitate toward dark-purple/blue themes like palenight, onedark, tokyonight, etc, and also have a huge love for gruvbox because of how easy it is on the eyes, even if it sometimes looks baby-green (parents know what I mean). The Modus themes are in the same vein as palenight/onedark but are incredibly customizable and readable. On first load, modus-vivendi-tinted was passable but not my favorite. After spending some time with it, researching the excellent documentation, and making it work for proof-of-concept, I’ve found I really like it. Customizing takes some work, but that’s part of the fun. The point is that I would not have discovered this unless I deliberately gave built-in functionality a try.

I’ll also add that a similar theme to Modus-Vivendi can be found on Vim: zaibatsu default colorscheme with only a few tweaks (background color, etc).

In short time I have basically rewritten my Emacs config and done so in a way that is much smarter imho. And I’ve learned a ton of the nuts-and-bolts of Emacs. In another post I’ll go through my config line-by-line-ish, but for this one I’m just going to share some principles I’ve adopted in writing my config.

My Guidelines for Writing My Emacs config:

1. If you’re short on time, Doom and other pre-built configs are far better than a quick, franken copypasta’d “custom” config.
2. Avoid copying old (or any) guides.
3. Identify the functionality you need and base your package selection off that.
4. Know the built-in solutions first.
5. Look at alternatives before selecting one.
6. Be consistent with package calls, i.e. either utilize use-package or don’t.
7. Use early-init.el.
8. Split your init.el into multiple files.
9. Literate configs should not be necessary.
10. Evil-mode: use evil-collection and general.
11. Custom keybindings should be completely unique for functions without existing keybindings.
12. Custom functions should be identifiable as custom.
13. Create an additional static “rescue” init.el facsimile with bare-bones built-in configuration.

In another post I’ll go into detail each of these points, and perhaps add to them. For now, ponder them for yourself and develop your own interpretation or opinion about them. These are my opinions, you may (and should reasonably) disagree with them.

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.

My Background regarding the SSPX

During my second year of college I began attending the Traditional Latin Mass (TLM), which was at an Fraternity of St. Peter (FSSP) apostolate a reasonable drive away. For those who don’t know, the FSSP was founded by former SSPX members who disagreed with SSPX founder Archbishop Marcel Lefebvre’s decision to consecrate 4 bishops without Rome’s approval in 1988. As a result the priests of the FSSP are anti-SSPX to varying degrees, mostly hardline. There was no SSPX presence near me at college nor where I grew up. I didn’t have strong feelings towards the SSPX other than I did not believe I could attend their chapels and I found their website harsh (in hindsight they had a pretty decent site layout, I don’t even think they were using https). I began to follow the SSPX closer when their negotiations with Vatican began and ultimately failed around 2009. I attended the FSSP almost exclusively until 2013 when I moved to an area with no FSSP presence.

Around 2019 I transitioned away from a stressful job with long-hours [finally] had [some] free time on my hands. I became a big consoomer of traditional Catholic media, listening to good number of the usual podcasts (Marshall, Remnant, Flanders, Fatima Center, etc) whilst commuting and touching/mowing grass. I read a ton of the standard trad books (Gruner, Ferrara, Davies, +Lefebvre, etc), and overall kept up with the goings on in the Church - at least within my segment of the hoi poloi.

I became sympathetic to the position of +Lefebvre and believed that he acted in good faith. I gained perspective towards him and understood that he was a practical man, a missionary for most of his clerical career, and was used to having to diy in the bush of Africa. Whether he was right or wrong to consecrate said bishops in 1988 and incur what normally would be automatic excommunication, I realized in his own eyes he was making a prudential judgment in a situation that went beyond the letter of the law - I daresay even an inconceivable situation (queue guy from Princess Bride) - believing his obligation before God was to follow not the letter, but the spirit of the law. I concluded that even if he were wrong his decision, he was in good faith and as a result was protected from excommunication in both the 1917 and 1983 codes of canon law, which have a few exceptions for state of emergency, necessity, etc. Far more learned men have come to the same conclusion. ¹

Furthermore in reviewing Rome’s correspondence with and regarding the SSPX since the early 1990s, I came to believe Catholics could attend SSPX chapels provided they do not take on a schismatic attitudes (I’m omitting details here). If you drew a line in the sand and asked me if +Lefebvre was right or wrong side of the line, I would say right. I began attending the local SSPX chapel as I viewed it as the best option in my area for my family. If there was an FSSP, ICRSS, or consistent diocesan church around, I would have probably attended those instead.

TL;DR:

I say all this as background to explain that:

1. I have been on both sides of the SSPX issue.
2. I have considered all sides to some [hopefully adequate] degree
3. I still am not hardline one way or the other.
4. I acknowledge that I could be wrong.

The Crux of the SSPX: Crisis and Necessity

The correctness or even liceity of the SSPX hinges on the fact that:

1. The Church is in a crisis.
2. There is a necessity for bishops to continue the mission of the Church (could also mean a state of emergency).

That’s it, really. To be squeaky clean, you really need both of these to be true.

Talking Heads

Since around 2022 I have mostly removed myself from consoom Catholic media. For the most part it is a distraction for me. I make except for Avoiding Babylon for the lulz and meme content. There is nothing about the faith I can’t learn from books I have, and there is nothing truly important that I won’t find out from the pulpit or some meme chats. I am not saying you need to tune these out or falling into the classic “you’re not a real Catholic unless you ___” fallacy, but especially with Lent upon us I would advise at least considering it. Plenty of the talking heads laudably take time off during Lent.

Regarding the recent SSPX announcement, I have deliberately not cared much what others have said about it. I will now contradict what I just said and say that from a cursory glance of the headlines it seems the response has been fairly measured and optimistic, especially considering there is time. This is a good thing.

Thought Experiment - the actually schismatic SSPX2

It is the year 2026. The fictional SSPX2 has existed as a formal parallel church since 1970 and has set up its own dioceses since then. The conditions in the Church are otherwise exactly as they are now. We treat the SSPX2 as heretics and formal schismatics.

With that being said:

1. Is there a crisis in the Church?
2. Is there a need for Catholic Bishops?

If you ask any faithful Catholic who attends anything to the right of a garden variety American Novus Ordo, he will almost certainly say yes to both of those questions.

So if Bp. Someguy decided out of necessity he was going to consecrate bishops so that the sacraments of confirmation and holy orders could be continued (and more things), would he be justified under the current circumstances?

If not, I don’t necessarily fault you for saying so; you are saying so out of filial obedience to the Church. But my question to you would be:

1. What would be the point at which we are in a crisis and/or it becomes necessary?
2. If there is never a point where consecrating bishops (or breaking some other disciplinary law) is justified, then why does canon law even give qualifications for doing such things? Why would it leave those kinds of outs?

My Take

Looking at everything from a 30k ft view (that’s about 10km, long live the Empire) over the last 100 years or so, I don’t know how much worse it has to get before we can officially call it a crisis. It seems to quack quack a lot louder than a single duck. I would say even if 25% of the churches were in as bad shape as the average one is today (or was in 1970), we’d be in a crisis (though we might have enough bishops in that case).

Likewise when there are literally single-digit number of bishops who we call /ourguy/ - and the lead of them is an Auxiliary Bishop from Kazakhstan - I’m not sure how we can say there isn’t a need for bishops. Fortunately a number of them still have some time left - provided they don’t get Cdl. Pell’d (RIP) - in 10 or 20 years how many will be left? Are any of the good diocesan or religious priests getting elevated? Who is determining who becomes bishop (aka “king makers”), and who has been elevated over the last 15-ish years? Is there any end in sight to this? Can we even see an inflection point where things begin to slow down?

Perspective is Key

I ask that anyone who feels strongly one way or the other, please have charity and steel-man your opponent.

If you are strongly against the SSPX, please read the works of +Lefebrve, especially Open Letter to Confused Catholics. Read his biography, watch his documentary. Do everything you can to gain his perspective.

Afterwards if you don’t think he was justified, that’s alright, just have an answer as to when he (or someone) would be justified in doing so.

Put yourself in the shoes of a faithful bishop in 2026. What would you do? What would you feel comfortable bringing to your judgment? I don’t envy any of these men, it is a hard decision all around, and I think it would take a tremendous amount of fortitude to faithfully choose one side or the other. It is not a clean win-lose situation, but a bad-worse situation.

Above all I pray God’s will be done. AMDG.

Purple.

Septuagesima

From the Catholic encyclopedia:

(Latin septuagesima, the seventieth).

Septuagesima is the ninth Sunday before Easter, the third before Lent known among the Greeks as “Sunday of the Prodigal” from the Gospel, Luke 15, which they read on this day, called also Dominica Circumdederunt by the Latins, from the first word of the Introit of the Mass. In liturgical literature the name “Septuagesima” occurs for the first time in the Gelasian Sacramentary. Why the day (or the week, or the period) has the name Septuagesima, and the next Sunday Sexagesima, etc., is a matter of dispute among writers. It is certainly not the seventieth day before Easter, still less is the next Sunday the sixtieth, fiftieth, etc. Amularius, “De eccl. Off.”, I, I, would make the Septuagesima mystically represent the Babylonian Captivity of seventy years, would have it begin with this Sunday on which the Sacramentaries and Antiphonaries give the Introit “Circumdederunt me undique” and end with the Saturday after Easter, when the Church sings “Eduxit Dominus populum suum.” Perhaps the word is only one of a numerical series: Quadragesima, Quinquagesima, etc. Again, it may simply denote the earliest day on which some Christians began the forty days of Lent, excluding Thursday, Saturday, and Sunday from the observance of the fast.¹

The Church in her wisdom gives us a time prior to Lent so that we may better be prepared for the Lenten season. It is supposed to be a time of fasting and penance, and nobody who seriously takes up that practice - or any bodily practice - jumps in cold turkey with a day’s notice. The idea is that the entire 40-day period (it’s not quite 40 days, just like Septuagesima/Sexagesima/Quinquagesima aren’t actually 70/60/50 days respectively. Math is hard.) is a time of fasting and prayer in preparation for Easter. Lent isn’t meant to be a 40-day journey where we gradually ween ourselves and hopefully by Easter we’re able to fast for a day or two.

Ideally we are so aware of the liturgical year that at all times we know how many days remain until Lent and so we can be prepared on our own without any reminders. Rephrased: ideally we should not have concupiscence and other effects of Original Sin. Unfortunately that is not how people are, so the Church gives us these visible reminders that Lent is coming. The colour is purple which we only see in Lent and Avent; the Gloria is ommitted; the Epistle and Gospel readings have a more penitential or reflective tone so that we are encouraged to reflect on the Mercy of God and where we need to be in 3 weeks (and at the end of our lives).

This is not a practice isolated to the Latin Church, and it has its parallels in the Greek Church with Meatfare and Cheesefare, plus with similar trends in the readings. This is a universal (i.e. catholic) practice meant to strengthen our weak human nature, which is yet again something the authors of the Novus Ordo - who at least claimed to appeal to ‘modern man’ and the East - got completely wrong.

When I attended the NO - which has been over a decade ago at this point - it very frequently happened that I would show up to Mass on Sunday with Fr. in green vestments, not knowing what Sunday it is in Ordinary Time, and there might be a comment in the homily that Ash Wednesday is this week. I haven’t changed, so I was just as forgetful or side-tracked as I am now. That gave me 3 days to quickly move away from feasting and consooming product to the opposite. Then whatever things I wanted to do for Lent generally didn’t happen at the start, which means they pretty much didn’t happen. Failing in our resolutions is inevitable to at least some degree, but it sure helps if we at least have a fighting chance and make headway from the get go. That initial momentum helps us make it to the end.

So, if you’re like me and completely forgot about Septuagesima Sunday, that is completely ok. The Calendar is designed with us in mind. It’s part of the plan - trvst the plan.

I wish you all a blessed [preparation for] Lent.

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.

• Artix Linux
• Unix Digest
• Bogleheads
• Official Ninja Webpage
• Hecking based website

GNU/Linux References

• Readline Cheat Sheet

Frens

• Heaventree
• Denshi
• Joshua Blais
• Matthew Kennedy
• tony, btw
• cashmere

Channels I regularly consoom

tech:

• learnlinuxtv
• system crafters
• prot
• dt
• tony_btw
• joshua blais
• denshi
• dj ware
• kris occhipinti
• unaboomer
• Old Tech Bloke (RIP)

Catholicism:

• SSPX Podcast
• Sensus Fidelium
• Avoiding Babylon

finance:

• Ben Felix
• Patrick Boyle
• The Money Guy
• DiamondNestEgg
• Strong Man Personal Finance
• RJ Financial / Run on the Bank
• Bank Account Bonus Central
• Clark Howard

I have many interests and my site is or will be a way of documenting them - GNU/Linux and tech of course, but also Catholicism, personal finance, credit cards/bank account churning, cycling, ball and disc golf, home improvement, and many more. Computers in general and GNU/Linux specifically are one of many interests, but one I consistently keep busy with and will hopefully be able to as long as I live.

By education I am a mechanical engineer. Initially I was a CS minor until it became more time ($) than it was worth. Currently I am a design engineer for the electrical utilities. In my past life I was a submarine officer and in another past life I was a Catholic seminarian.

My first introduction to GNU/Linux was when I was a kid in the 90s through my late father who was a hobbyist GNU/Linux user. He passed away when I was a youngster from cancer, and it wasn’t until university that I became re-acquainted with GNU/Linux via Ubuntu (08.04). I dual booted Ubuntu and Windows Vista via wubi (RIP in peace) and haven’t looked back - other than now running neither Ubuntu nor Windows.

codeberg