TeraPad, Sakura Editor, Hidemaru.

Looking back, text editors were always just “little tools” for me. Something for taking notes or glancing at log files. The main stage of development always belonged to an IDE, and my work with Unreal Engine was, of course, no exception.

And yet, look at me now.

I’ve left the IDE, I’m even building my own Nvim plugins, and I find myself trying to return to that development environment built around what I used to think of as a “mere text editor.”

It’s a strange thing.

This is a short, personal story (or “poem,” if you will) tracing my journey with text editors.

With IDE-Like Editors

My story goes way back, to a time when I was developing with CodeWarrior.

The IDEs of that era, looking back now, weren’t all that smart. Perhaps it was because my own development style was a bit quirky—I used a lot of assembly—but I gradually started to think, “Maybe I don’t really need an IDE.”

Before I knew it, a text editor was at the center of my workflow.

It wasn’t Hidemaru or Sakura, though. It was an MDI (Multi-Document Interface) based editor that could manage multiple windows in tabs and even display a project file tree. It was an editor that still held the shadow of an IDE.

(Unfortunately, I’ve completely forgotten its name. It’s times like these I wish you could search Google by filtering for a specific range of years.)

And the Magic of Emacs

One day, as I continued my work in a text editor, I saw something incredible.

The senior developer sitting next to me was wielding his editor like a magician.

He was reading email, checking the bug tracker, and then, without missing a beat, seamlessly started writing code, all within his editor.

“How cool is that,” I thought, honestly impressed.

When I asked him, full of excitement, he told me it was “Meadow,” a variant of Emacs. That was the moment I first encountered the culture of “Linux-style editors.”

And then, being young and impressionable, I was soundly defeated by Emacs.

No matter how hard I tried, my fingers just could not get used to those unique keybindings, all starting with C- (Control).

And Vim, A Place to Call Home

It was around then that I met the other editor: “Vim.”

With its concept of “modes,” Vim is perhaps an even more peculiar editor than Emacs, at least when it comes to the singular task of text editing.

And yet, strangely, this one clicked with me.

It was that odd sense of relief, knowing that “when in doubt, just mash the Escape key and you’ll be back in Normal mode.”

And above all, operations that required complex key combinations in Emacs were, in Vim, like casting a spell (a command), such as typing :w. At the time, I just felt that this was “somehow cool.”

That was the start of my slow descent into the Vim rabbit hole.

The Bottom of the Rabbit Hole

Sunk deep in the Vim rabbit hole, I could never forget the impact of that Emacs-wielding senior developer.

“I want to do everything in Vim.”

Dreaming of this, I tried all sorts of plugins. But I immediately hit walls. “Ah, that’s really more of an Emacs thing,” or “Vim’s asynchronous support is a bit...”

Still, when I heard a Twitter client that ran in Vim was released, I used it with glee, soaking in my own self-satisfaction.

After several years of this, I suddenly reached a very calm state of mind: “An editor is, after all, just an editor.”

My stance had changed.

I stopped “trying to do any and everything in Vim” and shifted to “doing what Vim does well, and doing it comfortably.”

Of course, my stance of “if a fun-looking plugin comes out, I’m going to try it” hasn’t changed a bit.

I had chased that dream of “Vim as an OS.” Perhaps this feeling means I’ve finally touched the bottom of that rabbit hole and have simply stopped struggling.

The rabbit hole of the Vim editor itself is one I’ll probably never see the bottom of in my lifetime. But now, I feel like I’m just searching for my own comfortable spot on its shore.

Window Splitting and Unite

As I continued to develop, our libraries gradually bloated, and the total number of files in our projects grew.

The accuracy of my ctags completion plummeted, and the tag generation time itself became horrendous. I was barely writing any assembly anymore, and the developers around me were all moving to IDEs like Visual Studio.

But I kept using Vim.

There was one reason and one reason only: the ability to edit a class while seeing the header and source files at the same time. Or to work while referencing multiple header definitions.

This “window splitting” feature, and the comfort of using it entirely without a mouse, was just too useful for me.

However, with these bloating projects, a file browser became essential. A tree-view plugin was indispensable for navigating between classes scattered all over the place.

It was around then that Unite and CtrlP appeared.

No matter how scattered the files were, I could usually guess the target filename, and if I was #include-ing it, I knew the name instantly.

For me, someone who had failed at Emacs and knew only the world of Vim, this was a true breakthrough.

(Only later, after reading articles by shougo-san, did I learn that this concept had long existed in Emacs in the form of anything.el.)

Because of this encounter, I rarely, if ever, used a traditional file browser plugin as a daily driver, right up until I met Unreal Engine.

Omnisharp and LSP

When I started helping out on a mobile game using Unity, I thought, “I wonder if I can write C# in Vim?”

At the time, I was splitting my workflow: game code in Vim, but C# code strictly in an IDE. The reasons were simple: no code completion, definitions were hidden inside DLLs, and writing something as complex as XAML from scratch was just too painful.

But the timing must have been good.

Just as I was searching for “C# in Vim,” Omnisharp appeared.

(Its magical functionality would later become the standard we all know as LSP.)

Having acquired glorious code completion in Vim, I never touched the IDE for that Unity project again, except for debugging.

And Unreal Engine

In the midst of all this, I encountered UE on my next project.

By then, LSP had become a widespread standard, and I naively thought, “This will probably work smoothly with UE, too.”

Reality was nothing like that.

In the early days, I couldn’t even get a compile_commands.json to generate properly in my Windows environment. I found myself creating massive .clangd files like some kind of “magic incantation,” just trying to trick LSP into working.

I would launch Vim in the morning, but if I touched the IDE even once, I wouldn’t return to Vim for the rest of the day. Those were the days.

UE5 and Now

UE5 was released, and as the versions ticked up, the compile_commands.json output finally stabilized.

“Now is the time. Once more.”

I felt it was time to return to my old style: “Code in Vim, debug in the IDE.” And so I started developing the plugins to make that happen. That’s where I am now.

The Future and Nvim

I will probably keep using Nvim for the rest of my life.

It feels almost like a curse, but my hands have learned it, and it can’t be helped.

And if I ever use an engine other than UE5, as long as it’s made with C++, I’m sure the first thing I’ll do is start by figuring out how to generate a compile_commands.json.

I might even find myself writing a similar set of plugins to the ones I’m making now.

This is an industry with a lot of NDAs. If it’s a closed-source engine, I’m sure my own private plugins, never released to the world, will be quietly created.

(The story of my migration from Vim to Nvim is one for another time.)

Anyway, that was just my little “poem.”