Skip to content

Article: From Emacs to Neovim - a retrospective #7

@practicalli-johnny

Description

@practicalli-johnny

Write an article on my switch from Emacs to Neovim over the last couple of years, in the style of a retrospective.

Emacs to Neovim - a retrospective

The following is a brain dump to help organise what I want to put into the article.

I've spend the first decade of my Clojure development life using Emacs and have had great success.

I used the Spacemacs community configuration for most of that time, initially starting with Emacs Live (mainly because it just worked and had a cool cyberpunk theme).

Spacemacs really helped me understand what was possible with Emacs. Instead of hunting for packages or writing lots of (probably quite back) Emacs Lisp code, I could add a layer that provided a feature set made from packages that were skillfully wired together.

Spacemacs also had an excellent mnemonic which-key menu (a text menu in Emacs that was keyboard driven).

The upshot was that I could focus 99% on getting better at Clojure rather than reinventing things to a lesser standard.

Without Spacemacs I would have grown frustrated with Emacs (or maintain my own dodgy emacs config, spending far less time on Clojure and Practical.li content).

Emacs challenges

In an attempt to make Emacs even faster I started using native compilation. Whist it made some things seem better initially, the overall experience seemed to become worse. Native compliation also added a bit hit to the initial install time due to compiling all the packages (around 270 packages in my Spacemacs setup).

The biggest issue was rendering the text when I was on a role typing. I can type 60 to 80 words per minute when writing docs and Emacs seemed to struggle to keep up.

This issue may have been multiple factors and I assume native compilation should have been redone on major library version changes (and Emacs versions too - but that would be managed by Spacemacs downloading the packages again for the new Emacs version)

Deciding to try Neovim

A trusted colleague encouraged me to give Neovim a try. I did some research about Treesitter incremental parser that was not part of Neovim and was impressed by the potential. Neovim had also recently added a built-in LSP client.

The Lazy Package manger was becoming more popular and looked a much nicer experience than those I tried before. Coupled with Mason for installing LSP servers, format and lint tools, the on-going maintenance looked very simple.

I already knew about the Conjure plugin that provides an excellent Clojure workflow for Neovim.

So there was lots of motivation to try Neovim, I just had to figure out how to use it without spending the next year hacking on a configuration :)

The challenges

  • How to configure Neovim (no vimscript, sorry)
  • How to adopt an effective Neovim workflow (focused on one neovim instance per project)
  • Adopting an effective Clojure workflow (Conjure and Portal made that really easy)

A spicy start

As Conjure was written in Fennel and Fennel is a very nice functional language similar to Clojure, then that seemed the best approach.

Examples and documentation for configuring Neovim was centered around Lua (and vim/vimscript), so using Fennel was more of a challenge.

Oliver Caldwell (Olical) improved the tool chain for fennel by creating nfnl and moving away from Aniseed.

However, this would mean committing Lua code into my Neovim config repository.

Community Configurations

AstroNvim an obvious leader

  • well crafted
  • easy to maintain and modify
  • uses lazy package manager

Emacs is still beloved

I would still use Emacs for some activities (software archaeology and really heavy refactor of large code bases) and it Emacs is more feature rich than Neovim.
I haven't needed as many features in the last couple of years and its been nice to focus on editing speed and simpler interactions with the editor. Also just to try something new.

I keep an interest in Emacs, especially Clojure Mode for treesitter. Once treesitter is widely adopted by package maintainers it should give Emacs a significant boost in performance.

Emacs has also merged Pure GTK libraries, so the UI should be more responsive (especially on Linux +Wayland and maybe Windows + WSL)

Metadata

Metadata

Labels

No labels
No labels

Projects

Status

In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions