A rundown of features added since last post https://xenodium.com/agent-shell-0-63-updates

Hello! I'm a long-time Vim/Neovim user, and I've wanted to try Emacs for a while. I finally decided to use it for a month to see whether it could become my daily driver and main editor.

Here are my dotfiles for anyone interested in seeing my configuration.

I tried to replicate my Neovim setup as closely as possible while still respecting the “Emacs way” of doing things. I used built-in features whenever possible and only installed packages when I felt they were truly necessary.

I tested Emacs for almost all of July 2026 using GNU Emacs 30.2. These are my thoughts so far.

Keybindings

I got used to the Emacs keybindings surprisingly quickly and experienced very little friction. When I'm in the terminal, I already tend to use shortcuts such as C-a, C-e, C-k, C-f, and C-b to move around.

I don't think the default Emacs keybindings are that bad. Most of them are actually quite good. I even find some of them faster than their Vim equivalents, and they are not too difficult to get accustomed to.

However, some keybindings are genuinely unpleasant. M-v, for example, feels awkward to me. In general, many of the Meta-based bindings are not particularly comfortable.

Code Navigation

This is one of my biggest issues with Emacs.

I dislike how dependent code navigation is on the package ecosystem and the quality of individual major modes. To navigate efficiently through code structures, you often need a well-written major mode.

In Vim, basic text operations work consistently regardless of whether you are using Java, C, PHP, or another language. You can operate around common structures such as parentheses, brackets, braces, and quotes without relying heavily on language-specific support.

These structures are common across many programming languages, so I would prefer Emacs to provide more consistent built-in ways to navigate and manipulate them.

For example:

(message "hello beautiful world")
;;               ^
;;               Cursor is inside the quoted string.

Pressing C-M-k here deletes only the next expression, which in this case is the next word:

(message "hello  world")
;;               "beautiful" was deleted.

To delete the entire string expression, the cursor must first be moved to the beginning of the string:

(message "hello beautiful world")
;;       ^

This feels unnecessarily precise compared with Vim's text objects, where the operation works as long as the cursor is somewhere inside the quotes.

Before someone suggests Evil Mode: I personally dislike the idea of using a Vim emulation layer. It is not really Vim, but it is also not really standard Emacs. To me, it feels like being stuck in an awkward middle ground rather than fully using either editor.

Built-In Features

Most of the built-in features are excellent. Some of my favorites are:

• Dired
• project.el
• completion-preview
• use-package
• Org Mode

However, some built-in features still feel incomplete.

Eglot

Eglot was straightforward to configure. I tested it with Intelephense, and it worked flawlessly.

However, I was disappointed to learn that using multiple language servers in the same buffer requires an LSP multiplexor.

That feels like a significant deviation from the behavior of many other editors, and it adds complexity that I don't particularly want to manage.

I am aware of lsp-mode, but it seems heavier than what I am looking for.

As it stands, Emacs has a solid built-in LSP client, but its limitations prevent me from comfortably using it as my daily driver.

Tree-sitter

The current Tree-sitter experience is not good.

I understand that it is still a relatively new feature and that many major modes do not support it properly yet. I have also seen that Emacs 31 is expected to improve the situation.

However, in Emacs 30.2, it does not feel particularly usable for my setup. It requires too much boilerplate, and I don't want to spend time maintaining that configuration.

I have high hopes that Tree-sitter will eventually improve the code-navigation issues I mentioned earlier by allowing structural navigation based directly on syntax-tree nodes.

Packages I Used

I would also like to mention the packages I used while configuring Emacs, in case anyone else is going through a similar journey.

Doom Themes

Doom Themes

There is not much to say here. I used the doom-gruvbox theme, and it looks great.

Reformatter

Reformatter

This is a lightweight and straightforward package for configuring code formatters.

I used it to set up:

• php-cs-fixer
• nixfmt
• xmlstarlet

It worked very well.

inhibit-mouse

inhibit-mouse

I wanted to force myself to use the keyboard, so I installed this package to disable mouse input.

It worked well, although I was surprised that Emacs does not appear to provide this as a simple built-in option.

direnv

emacs-direnv

I use Nix and direnv to manage my development environments and environment variables, so this package was essential for me.

It worked very well and integrated seamlessly with project.el.

Ghostel

Ghostel

This is a great package.

I almost gave up on finding a good terminal emulator embedded inside Emacs, but then I discovered Ghostel. It works extremely well and feels very fast.

It was probably the MVP of all the packages I tested.

Git Gutter and Magit

Git Gutter and Magit

Git Gutter is a great package for viewing and interacting with Git hunks directly inside a buffer.

Magit probably does not need an introduction. Almost everyone already knows about it, and it is excellent.

Final toughts

Overall, my time with Emacs was much more positive than I expected. I enjoyed many of its built-in features, and the general extensibility of the editor. However, code navigation, structural text editing, Tree-sitter support, and Eglot's limitations are still big issues for me. For now, I don't think Emacs will replace Neovim as my daily driver, but I will continue following its development.

Where an exercise to automate copying over a GitHub issue into Org Agenda turns into a think-piece on malleable computing in Emacs.

I'd like to introduce JAL (Java Agent Loader), a package I developed for Java developers using Emacs. JAL extends lsp-java or eglot-java (both required dependencies) to automatically detect and configure Java agents in your projects, removing the need for manual setup. It supports both Maven and Gradle builds for seamless integration with common Java project structures. JAL works out of the box with popular Java agents like Lombok, JaCoCo, and OpenTelemetry. You can find JAL on GitHub and install it directly from Melpa. If you want to simplify and automate Java agent setup in Emacs, I encourage you to give JAL a try.

(use-package jal
  :custom
  (jal-auto-setup t)
  :config
  ;; Optional: override known agents or add new ones
  (jal-additional-agents
        '( ;; Override a known agent with custom parameters
          ("org.jacoco.agent" :params "destfile=target/jacoco.exec")

          ;; Add an agent not in the known list
          ("my-custom-agent" :jar-path "/opt/agents/my-agent.jar")
          ))
  (jal-lsp-java-mode 1)) ; or (jal-eglot-java-mode 1)

I’d like to introduce trailing-newline-indicator, a simple yet effective Emacs package that brings visual clarity to a subtle but persistent editing issue: knowing whether a file actually ends with a trailing newline.

While many Emacs users rely on configurations like require-final-newline or automated save-hooks, these silent approaches have clear limitations. Configs can fail silently, leak across buffer types, or be bypassed in unformatted buffers like quick notes, scratch files, and third-party major modes.

Relying on built-in visual tools also falls short:

• The Emacs C-Engine Limitation: Due to how Emacs treats newlines as line terminators rather than line generators, native line numbers (display-line-numbers-mode) leave the trailing position completely unnumbered. As discussed in this thread, standard fringe indicators do not treat that space as a newline, and the maintainers have no plans to change this behavior.
• UI Noise: Options like indicate-empty-lines apply markers to every empty line past the end of the buffer, cluttering your window instead of targeting the actual point of ambiguity.

trailing-newline-indicator solves this cleanly and surgically. It places a single, subtle visual marker in the line-number margin or fringe only at the true end-of-buffer position. It performs a quick, instant check at the very end of the file rather than scanning the entire document, making it completely lightweight and imperceptible even in massive files. You get unambiguous feedback with zero UI clutter or performance penalty.

You can find the package on GitHub, and it’s also conveniently available through Melpa.