zeizig

One interesting feature is compilation to Lua byte code which kanagawa.nvim supports. It should improve start up times.

I’ve been using Neovim for quite a few years already and am quite happy with the choice (but haven’t touched Emacs). I think that the killer feature of Neovim isn’t the modal editing (that can be emulated in most editors), but rather the extensibility. It can be configured to suit pretty much any workflow. That’s partly a reason why I think using a Neovim distribution is not super helpful, it includes someone else’s preferred settings, mappings, and plugins, and you don’t know exactly what is available and why certain plugins were added. They can be a nice inspiration for your own configuration, though, and may be a good place to start if you don’t even know what’s possible.

kickstart.nvim is a nice starting point for your own config. It’s just a single file including the essentials that you can copy for your own configuration and start adding your own customizations on top of. As far as actual distributions go, then LazyVim seems to be a pretty nice one as the configuration is pretty much the same as configuring Neovim without a distro, so you if you ever decide to start your configuration from scratch, then you’ll have pretty good knowledge of how it’s done.

I’d recommend taking a look at this talk by TJ DeVries (core member of the Neovim team): PDE: A different take on editing code where he proposes the term “Personalized Development Environment” for describing Neovim. Here’s another one where he sets up a configuration with kickstart.nvim: Effective Neovim: Instant IDE.

Another powerful thing about Neovim is that it can be configured in Lua (a programming language, rather than JSON), meaning that you can do just about anything in your config. Here are some examples for making key mappings smart: 5 smart mini-snippets to amp up your text editing experience in Neovim (my own blog post, sorry for the shameless plug :D).

When comparing with VSCode, I think that Neovim can do pretty much anything that VSCode can do. The LSP (Language Server Protocol) support in Neovim allows using the same “editor smartness” features as VSCode has. nvim-dap enables debugging with the same debuggers as in VSCode. Neovim also has built-in support for Treesitter, which exposes a syntax tree of the current file for syntax highlighting or for plugins that can do all sorts of fancy things with it (which is even smarter than VSCode) (there are some examples in my blog post linked above).

A few things that come to mind (from small scale to larger scale optimizations):

• Editor keybindings, editing code fast and conveniently (and having fun while doing it). Vim helps a lot here, but knowing the shortcuts in any editor (or other applications you use) is important.
• Inline linting and compilation errors in the editor.
• Static typing, your editor will already let you know if what you’re doing makes sense, and gives you suggestions on what you should do next.
• Automatically running automated tests inside the editor, or just in a separate terminal tab.
• Automatically recompiling code whenever it is changed. Something like Vite makes this very fast for web dev.
• Hot module reloading avoids reloading the page after every change.
• Automation in general avoids human errors and reduces the number of feedback loops. I quite like do-nothing scripting for this.
• Using Docker avoids parts of the feedback loop for setting up a project entirely. Set up scripts improve it further.
• Good documentation for setting up a project avoids the feedback loop of asking other devs for help.
• A fast and convenient development environment makes things nicer in general.
• If you use the conventional commits commit message format, then running the commit message linting right after writing your commit message.
• Running code checks any time code is pushed. Even if you don’t run linting or check for compilation errors locally, your pipeline should still catch any errors as early as possible.
• UI tests check if the main flows in your application are working, avoiding manual work of testing after deployments.
• Continuous integration, merging code to the main branch as often as possible reduces conflicts and makes working in parallel with others easier. You get feedback about merge conflicts much faster.
• Continuous deployment, you get quicker feedback from clients about your deployed code.
• Error monitoring, know about runtime errors before clients report them.
• Feature flags allow releasing features to some customers earlier, getting feedback earlier. This also enables decoupling releases from deployments.
• Analytics helps to understand user behavior, allowing you to quicker make decisions about how to develop your product. This allows avoiding user interviews in some cases.
• Sitting in the same room as your team (devs, designers, pms) shortens the feedback loop of asking them for input while working on your tasks. Remote work makes this more challenging, of course.
• Having detailed designs in Figma shortens the feedback loop of asking designers for input. E.g., how many pixels should this padding be?
• Code reviews allows you to get feedback on your code before it’s merged and causes problems in the future.
• Design reviews (showing your implemented designs to your designer before merging) allows you to get feedback on your implementation earlier and avoids a new pull request with fixes.
• Sitting down with your QA and testing your code together allows you to find mistakes in your code earlier than when QA tests your code in production after merging.
• Releasing features often in small increments rather than a big release after many months of work (starting with the MVP and building on top of that) allows you to get feedback from clients often during the process. It’s also easier to pivot after a month of work rather than after 6 months. Splitting up features into smaller self-contained chunks is an art form on its own.

This ended up being a pretty long list, but I hope it was useful!

I’ve used IdeaVim, Vim, and Neovim for probably around 6 or 7 years or so, and wouldn’t switch from it. There are three of the main things I would bring out out, but there are probably many more:

1. It’s comfortable (for me) and fun. I’m so used to the keybindings that I don’t need to think about them at all. I just think that I need to change something, and it’s already done. It’s like magic! Flying through code like that is super enjoyable. I find that none of the IDE vim plugins quite hit the mark for me. I might need to try them out once again, as it has been a while since I last did, but I’m already quite used to the real ones.
2. It’s super extensible and configurable. You can really make it your own. I know that you can use plugins in VSCode (and there are a huge amount), and even write plugins yourself, but it’s so easy in Neovim. I think that a strength of Neovim is that you’re using a programming language for configuring your editor. There isn’t a huge leap when going from creating your first keybinding to making it do something extra that you need in your own workflows. I wrote an article recently, related to this exact thing: https://medium.com/scoro-engineering/5-smart-mini-snippets-for-making-text-editing-more-fun-in-neovim-b55ffb96325a
3. It’s fast. This isn’t that important to me, but it’s still something that makes day-to-day programming less of a drag. I can start Neovim in less than a second and there’s virtually no text input lag. I’ve seen how co-workers’ PHPStorm takes a minute or two to start up, and that seems quite upsetting.

There are other minor reasons like being open source, having a vibrant community, and being in the terminal, but those are less important to me than the big three.

I don’t really miss using a full IDE, because my Neovim already does everything I need it to do. It’s also lean as I know all the pieces that go into it and there isn’t anything unnecessary. I have completion that’s as smart as VSCode, but I don’t have a plugin for running tests inside the editor because I run them in the terminal.

Overall, I’m quite happy that I chose to try out Vim. It’s made editing code more fun, and that’s already a big win, I think.

Stray seems perfect, it’s mechanically easy, has puzzles, cute characters, an interesting (short) story, and a nice environment to explore.

Nice wallpaper! Could you share a link for it?