As I mentioned in my last post, I started using VSCode to see what I’m missing and I thought that it’s a good time to take all the risks and break my Emacs configuration. In the last changes, I tried to use the built-in alternatives of the packages like eglot instead of lsp-mode. Now I’ve made the decision to update Emacs to version 29.

When I first switched to Emacs 28, all my performance problems were solved thanks to native compilation support. Most of these problems were caused by LSP¹ and it was very annoying to wait even half a second to see syntax errors in the code. Now I don’t close Emacs on the server for months. This was the most significant change to Emacs 28 that I can’t forget.

Now, if you ask what the equivalent important update is on Emacs 29, I guess I can claim that Emacs has become quite useful even if you don’t install any extensions. Many extensions I used are now included in the project, for example:

• Modus-Vivendi and Modus-Operandi, the themes I have been using for years and cannot give up, now come in.
• The package configuration tool use-package is now included.
• The internal LSP service eglot is now available. I’ve previously used the lsp-mode extension.
• For tree-sitter support, nothing needs to be installed any longer.

Furthermore, TRAMP², which functions similarly to VSCode’s remote development extensions, has started to support Docker and Kubernetes; however, I have not yet verified whether LSP can be used in a remote development environment. I prefer to use MOSH³ to connect to the server and execute Emacs remotely, unless this occurs.

As many extensions were included, I also reviewed the other extensions I used. Although it is possible to use Emacs without any installed extensions, it is very difficult for me to give up some extensions. For instance, magit is far superior to many competitors, both as an Emacs and a git client.

Another extension that I can’t give up is doom-modeline. The default mode-line view in Emacs is also quite ineffective. It wastes space, uses the right half of the line very inefficiently, and shows minor modes needlessly. I began utilizing doom-modeline to address all of these issues. You can see the screenshot to see how it looks:

With Emacs 29, I suppose the major modification I made was to cease using popups for text completion. I’m not sure if it’s a good idea yet, but I’ll keep trying. I use all of Emacs’ capabilities that make use of minibuffers considerably more effectively by using the following extensions:

• consult: an extension for minibuffer completion.
• vertico: a minibuffer completion UI. It’s necessary for consult.
• orderless: completion style with various algorithms to find more search results.
• marginalia: an extension to see more information about the search results.

When I started using minibuffer instead of popup for completion, there was a lot of space left for a second text completion. so I thought why not use copilot or codium. Look at the screenshot to see how it works:

I didn’t turn on a lot of UI components, like line numbers, tabs, fringe, and scroll bars, so it’s likely that my configuration isn’t optimal for a graphical user interface. And to be honest, I didn’t need it; perhaps I’ll keep the UI in zen mode and continue using Emacs in my preferred terminal program, WeztTerm. But for the time being, I intend to continue working with VSCode. You may find a new version of Emacs with my setup in my emacs.d repository if you want to try it out.

---

1. LSP: Language Server Protocol ↩︎
2. TRAMP: Transparent Remote Access, Multiple Protocol ↩︎
3. MOSH: Mobile Shell ↩︎