Two Years of Emacs Solo: 35 Modules, Zero External Packages, and a Full Refactor

The "why" is kinda sketchy. The difference between what is shipped in Emacs and in ELPA is somewhat arbitrary. In fact, there are many built in packages that have their updates shipped in ELPA, meaning if you aren't using ELPA then your builtin packages might have unpatched bugs.

There's also no reason why you have to literally write everything yourself either. You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).

It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears. There is no shame or disadvantage in doing so.

Also, a critical objection:

> Writing your own packages is the best way to learn Elisp

Absolutely not. Reading a language is crucial. If all you do is write, you will pigeonhole into weird practices and generally fail to improve. Only by reading stuff written by others can you learn, as you're exposed to what other people do right and wrong, both of which will be different from you.

Of course, writing your own packages is also necessary, but not sufficient alone.

> That means the code is sketchy sometimes, sure, but it's in my control. I wrote it, I understand it, and when it breaks, I know exactly where to look.

This resonates with me so hard. I'm not a "no external packages" purist, but there are a number of pieces of functionality that I wrote for myself because there wasn't anything quite like what I wanted.

One example is a function to expand the region (selection) to any arbitrary set of pairing delimiters that I define in a defvar (parens, quotes, brackets, or I can can supply a custom left/right regex for matching). Then, when I execute the function, it waits for a second keypress, which is the trigger key I've defined for that matching pair, and it will expand the region to the left and the right until it meets the applicable delimiter.

Repeating the same key presses results in selecting the left and right delimiters themselves, and another repeat will extend to the next set of matching delimiters, and so on.

Even though I use a treesitter-based expand-region plug-in, my custom function is still invaluable for when I want to jump past a series of valid treesitter object expansions, or when certain text objects are just not defined in treesitter.

Some of the helpful custom expansions I have defined are:

"w" to select what Vim considers a lowercase-w word

Space to select what Vim considers an uppercase-W word

"$" to select ${...}-style expressions

"/" to select everything between forward slashes

"*" to select between asterisks (useful when editing markdown)

It's really an invaluable function for me, personally, but I always talk myself out of trying to open-source it because it has some gotchas and limitations, and I just don't want to be on the hook for trying to make everyone who uses it happy.

The only reason I'm still using emacs is magit (and muscle memory). I could not make magit myself.

Why are we so bad at naming things? Modules and packages are so abstract I need to google what they mean relative to the development environment just to move forward.

Is Eglot on par with emacs-lsp for C++? Specifically thinking about pointing it to a compile_commands.json and all of the usual C++ nonsense required for code navigation and autocomplete.

super impressive!! Going to steal some of this lisp for sure

This might be a paragon of masochism. Though, I am not only beyond impressed. I am beyond jealous as well.

I've been using Emacs since one of professors/mentors converted me over a decade ago back when I was attending university. As the years have progressed, I have found myself reaching for Emacs less and less. I still maintain my config and use it fairly often. I cannot use Emacs at my employer either, so that doesn't help.

However, I have always wanted to do what the author has demonstrated. I would love to be liberated from the all package dependencies I currently have. I just do not have the time nor self-discipline to do something like this. Even if the functionality would be less than or equal parity with 3rd-party packages, I would prefer the Devil I know over the ones I don't.