My Journey to the Perfect Text-Editor - Part 2

I wrote the article My Journey to the Perfect Text-Editor in 2012. I want to talk about my progession in text-editors since then.

This article is targeted at anyone interested in expanding their development environment or anyone interested in a relatively detailed journey of someone moving from using Atom to Neovim over a period of almost 10 years.

In this journey, you'll hear me mention CLI tools quite a bit later on. CLI stands for Command Line Interface, a type of software interface where users interact with programs by typing text-based commands. These tools are essential for many developers, offering a fast and flexible way to perform tasks that range from file manipulation to system administration and beyond. They're particularly powerful when used in conjunction with text editors like Vim, as they help to automate tasks, streamline workflows, and even extend the functionality of the editor itself. So while the article is for anyone, it does have a focus on Unix based operating systems (macOS, Linux, FreeBSD, etc).

Before I get into any specific editor, I want to summarise my goals for a text-editor in 2012, which is a point-summary of the previous article since this story continues from there. In 2012 I was working on HTML, CSS, JavaScript, PHP and some other scripting languages. I wanted the editor to fulfill the following crieria:

• Cross-Platform OS compatibility: I worked on multiple operating systems.
• Built for many programming languages
• Aesthetically pleasing
• Support plugins or extentions of the editor
• Powerful tool with Plenty of options
  • Find/replace throughout open tabs (I was quite specific with this
• Fast: I didn't like waiting for anything or feeling a type of lag.

Ultimately I landed on using SublimeText 2 since it satisfied the above points.

Disclaimer: When I talk about "Pros" and "Cons" or any opinions of an editor, keep in mind this was how I felt when I used the editor many years ago. So I probably have a completely different opinion of the editor today.

Atom (2014 - 2015)

I had gotten used to Sublime Text 2's multi-cursor tool and used it heavily and Atom released with this functionality.

Atom was developed by GitHub and its motto was "A hackable text editor for the 21st Century". Atom was built with Electron, a cross-platform tool to create desktop applications using web technologies, and is the reason Electron exists today. Atom supported extensive customisation through packages (read "plugins") built with JavaScript. At the time, JavaScript was still finding its place as a "real" programming language and Electron gave me hope and inspired me, as a JavaScript developer, to not only build tools for the web, but also for the desktop.

Pros

Atom's focus on JavaScript, being a highly accessible language compared to others, as well as it's open-source nature fostered a very active community immediately, which meant the editor could be extended in any way you could imagine.

I worked with JavaScript daily. Knowing that I could easily create my own package for the text editor was compelling for me, even though I ultimately didn't create one for Atom haha, but I did play around with it.

Cons

Atom was noticeably slower than SublimeText 2 for me. Load time of large files and just general scrolling and switching files had a delay that Sublime Text 2 didn't, but the things I valued about Atom outweighed the con of the editor speed.

Conclusion

• The ability to extensively customise the editor
• The ability to create plugins myself
• Easy to switch between projects
• Open-source and active community
• Be very fast and look smooth

VSCode (2015 - 2021)

Visual Studio Code (VSCode) was released in April 2015 by Microsoft. It was (and still is) a free, open-source code editor that's both lightweight and powerful. It focuses on modern web development and comes with built-in Git support. Its extensibility through plugins, a streamlined debugging experience, and its cross-platform nature, thanks to being built on the Electron framework, quickly garnered attention in the developer community.

I, however, was very skeptical to VSCode upon release for various reasons.

My issues with Microsoft at the time

By 2015 I had stopped using Windows entirely and solely worked on my Macbook Pro with OS X, macOS before the name changed. I was happy to have Windows out of my life and live in the Unix-based OS world. Developing in Windows for non-Microsoft related tasks was very cumbersome. Windows felt clunky and inefficient and I attributed these adjectives to Microsoft itself.

At the time, I was building websites which supported Internet Explorer 9 and 10 which were both far behind "modern" browsers like Firefox, Chrome or Opera. Earlier on in my career, I did development for Internet Explorer 6, 7 and 8. I was happy with the progress of IE9 over 8, but I was very disappointed in what IE10 brought to the table, especially after looking forward to its release day in October 2012 and with the knowledge that the next browser release would be very far away. I wanted IE to be better since a large portion of users were using IE as their primary browser.

With my deep-seated frustrations towards Microsoft—stemming from Windows' cumbersome nature for non-Microsoft tasks, the stagnation in Internet Explorer's development compared to more modern browsers, and the company's late entry into the open-source community—I was extremely skeptical of VSCode when it first launched.

With my frustration with Microsoft due to finding it cumbersome for non-Microsoft tasks and associating its inefficiencies with Microsoft as a whole as well as being letdown by IE and it's late entry into the open-source community, I was very skeptical of VSCode.

Initial thoughts after use

I didn't use VSCode for a few months since I was happy with Atom, but many co-workers were using it and were happy so I decided to give it a try. The transition from Atom to VSCode felt even smoother than SublimeText 2 to Atom. It felt like it was the same editor, but slightly better in almost every way; Almost like an Atom 2.0.

Continuing to use it as my primary text-editor was a no-brainer, since there wasn't a downside to it for my use-case, plus it felt a lot faster than Atom, which was the one downside I had when moving from SublimeText 2 to Atom.

Conclusion

• The ability to extensively customise the editor
• The ability to create plugins myself
• Easy to switch between projects
• Open-source and active community
• Be very fast and look smooth

Vim (2021 - 2022)

Vim is a robust text editor that operates within your terminal, known for its high customizability through VimScript and its keyboard-centric design. In 2016, a friend shared their experience with Vim, sparking my curiosity. It was a while ago, so I can't remember the specifics, but Vim's focus on minimalism, speed and efficiency certainly caught my attention.

When I first tried Vim, I found that it didn't match VSCode's efficiency for my needs. Even after spending time setting it up, certain essential features eluded me. This led to me frequently alternating between Vim and VSCode. For smaller tasks or single file edits, I leaned towards Vim, but for broader projects, VSCode was my go-to — akin to how one might switch between a basic text editor and a full-fledged IDE based on the task.

I used Vim this way from 2016 - 2021, so I gained familiarity with it, even though it wasn't my primary editor. Over this time, my proficiency with Vim's unique keyboard commands grew, making my workflow as fast as it was in VSCode, but freeing me from mouse dependency.

For a deeper dive into Vim as of 2022, check out this video by ThePrimeagen: Why I use Vim in 2022.

Not a final conclusion, since I hadn't swapped to Vim

• The ability to extensively customise the editor
• The ability to create plugins myself
• Easy to switch between projects
• Open-source and active community
• Very fast
• Minimal
• Efficient
• Experienced enough to use the editor to fulfill my own needs

What was stopping me from switching to Vim as my primary editor

I didn't know this at the time, but I was thinking about Vim in the wrong way. I was trying to replace VSCode, or any of the editors I had previously used with Vim alone. Vim can be extended to do almost anything, but it doesn't need to be extended, since we have other tools for the job.

I was struggling to switch between projects in Vim and I would have different terminal tabs open, each with a different instance of a Vim project. This wasn't working for me and I wanted something to switch between projects within Vim. While there are plugins for this, I struggled to get them to work and they tended to be a bit too complicated for me to set up.

Other big issues I faced included project-wide search/replace and open a list of files containing a specific search term, and a good Git plugin.

I don't know when the "Aha" moment was exactly, but I realised I didn't need to recreate all the VSCode functionality in Vim because I could just use existing CLI (Command Line Interface) tools for the job. I had read people suggesting usage with Vim in this way on forums, but I just wasn't in the place to understand it at the time.

• grep or git grep could be used to search through files for a specific term with a string or even regex.
• sed could be used to search for a string or regex pattern and replace with something else.
• git could just be used for my git needs.
• tmux could be used to handle different sessions (read projects) and windows within those sessions.

Instead of attempting to replicate the functionalities of VSCode within Vim, I had an important realisation. Vim doesn't need to be an all-encompassing tool; instead, I could leverage existing CLI tools to complement its capabilities. Whether searching with grep, replacing text with sed, handling Git operations directly, or managing sessions with tmux, I discovered that a synergy between Vim and these command-line utilities offered a powerful and efficient development environment.

Switching to Vim full-time

After the realisation about the synergy between Vim and other CLI tools in 2021 I relentlessly consumed Vim related content and came across a video of ThePrimeagen talking about TMUX and saw how he was able to quickly switch between sessions and I finally understood how I could commit to vim full-time. Since that day, I haven't switched away from Vim.

Conclusion

Vim not only fulfilled all my criteria for the perfect text editor but also opened up a new realm of possibilities by deeply integrating with CLI tools and the terminal environment. This shift away from GUI-based editors felt like a natural progression in my journey, instilling a sense of connection to the very roots of computing. It encouraged me to explore powerful command-line utilities resulting in a workflow that's both flexible and efficient. While VimScript could technically allow me to create my own plugins, my aversion to learning it became an issue as it prevented me from expanding on Vim myself without plugins. Overall, Vim was not just an editor for me, but more of a highly personalized development environment where I felt challenged, yet at home.

• The ability to extensively customise the editor
• The ability to create plugins myself (Note: While VimScript gives me the technical ability to create my own plugins, I've always had an aversion to learning it. So, technically, I could create plugins, but I personally didn't take that step.)
• Easy to switch between projects
• Open-source and active community
• Very fast
• Minimal
• Efficient
• Experienced enough to use the editor to fulfill my own needs

Neovim (2022 - Now)

I was aware of Neovim for a while by the time I was using Vim as my primary editor, but I didn't find a need to use it since it didn't add any features that would affect my workflow.

That was until they released version Neovim 0.5 in July 2022, which added support for Lua as a supported language for config and plugins, while still maintaining support for VimScript.

I didn't like VimScript, I found it cumbersome to use and I didn't feel a particular need to learn it since it was only used for Vim. I had a large custom VimScript config file, but it just did what it needed to do and I wasn't interested in learning more than I needed to.

When Neovim 0.5 was released, I kept a keen eye on how the community was adopting it. By January 2022 I rewrote my entire config in Lua. I found it very fun and rewarding. I found myself exploring the Vim API a lot more through Lua than I ever did with VimScript. VimScript felt like a means to an end, whereas Lua felt enjoyable and like I was growing.

The Neovim community feels vibrant and exciting and I'm really glad to be part of it!

Vim9Script

As of July 2022, an update to Vim was released which allows users to write their config and plugins in Vim9Script. This change has forced Neovim to hard-fork off of the Vim repo, which is unfortunate. Vim9Script looks a lot better than VimScript, but I'm happy with lua and don't plan on switching back to Vim.

Conclusion

Switching to Neovim felt like I'd found a piece of the puzzle I didn't know was missing. Lua not only became a fun and enlightening way to engage with my editor, but it also reignited my excitement for customization and plugin development. Unlike VimScript, which always felt like a necessary hurdle, Lua became a joyous part of the process. Beyond that, the sense of community in Neovim is electrifying. It checks all the boxes for me—from extensive customization and plugin support to an active, open-source community and a sleek, efficient design. At this point, Neovim isn't just a tool; it's a vibrant community and a constant source of learning and growth in my coding journey.

• The ability to extensively customise the editor
• The ability to create plugins myself
• Easy to switch between projects
• Open-source and active community
• Very fast
• Minimal
• Efficient
• Experienced enough to use the editor to fulfill my own needs

Honorable mentions

Emacs

I haven't used Emacs before but I know it's a very powerful tool that isn't limited to a terminal emulator, like Vim and Neovim are. While I haven't used it before, I know enough about it to know that it would score full points on my checklist of requirements.

I'm already in the Neovim world and I'm happy here; If fo some reason that were to change, Emacs would be at the top of the list of editors to swap to.

IntelliJ IDEA

Intellij IDEA offers a plugin named IdeaVim, which admirably supports Vi movements, basic VimScript configurations, and various IdeaVim plugins that emulate popular Vim plugins. IntelliJ is particularly proficient for Java and Kotlin development. For more complex tasks, especially within the JVM, I turn to IntelliJ with the Vi-Mode enabled.

Vi-Mode plugins in text-editors?

Vi-Mode is great and it's what I recommend to everyone since the Vi movements are amazing when you get used to them and if you can do that without leaving the comfort of your own editor, that's a plus. There are Vi-Mode plugins for VSCode (vscode-neovim), SublimeText ([Vintage mode]), IntelliJ (IdeaVim) and almost any GUI editor.

Applications are able to embed Neovim within them and VSCode has a plugin called vscode-neovim which does exactly that. Since it is literally running Neovim, not just a vi-mode emulator, you're even able to use a custom Neovim Lua config.

Comments I had received on the original article

I used to have a post-comment feature on this blog. When I wrote the first article in 2012, I received these two comments

I like using Vim on my Windows/Linux/Mac machines. It is cross-platform and pretty -- 7hao

Of course. Sublime Text is one of the most advanced editors today. I myself prefer Emacs (IMHO you can't measure it with other editors), but Sublime Text is very powerful also. -- Marko

To both of those comments, I say "Here here!". I completely agree with those two comments, but didn't understand them at the time since I didn't have a real understand on Vim or Emacs at the time.

Conclusion

Neovim has been a game-changer for me, not only meeting but exceeding what I sought in a modern text-editor. The shift to Vim initially opened my eyes to the power of keyboard navigation, improving both my speed and ergonomics. This journey has not only honed my skills in shell scripting and using command-line tools but has elevated my development process to what feels like "the speed of thought." It's as if tasks unfold effortlessly before me, making me not just a better developer, but one who feels in sync with my tools.

Many years ago, a good friend and I spoke about building our own text editor. We wanted to tweak and adjust every tiny bit to get it just right. Who would have thought that legends like Vim and Emacs were already out there, offering the very customization we dreamt of? Looking back, each editor I dove into, from Sublime's slickness and innovation to Neovim's extensibility and synergy with CLI tools, had its own charm and taught me something new. Right now I love Neovim, but the world of text editors and development environments is ever-evolving. While I have pushed myself to learn Vi-keybindings and explore new ways of working when I was already comfortable, I wouldn't suggest people make big changes, but I would definitely encourage others to learn something new about their development environment every week. No matter where I land in future, this journey has taught me that the perfect editor isn't just about features, it's about feeling right at home while also continuously expanding my understanding of how I can work.