Neovim Origin Story, An Emacs User's Perspective

"Academic politics is the most vicious and bitter form of politics,
because the stakes are so low." -- W. S. Sayre of Sayre's Law.

Vim author Bram Moolenaar took his title of Benevolent Dictator For
Life (BDFL) literally.  And like any good dictator, he surrounded
himself with advisers and regularly received legations to air their
grievances.  But the direction of his thumb, and his alone, decided
all disputes and motions.  That kind of unilateral control might work
for a low-profile library but not a text editor used daily by millions
of practitioners of that most prickly profession.  A hard fork of vim
was inevitable.

The final straw came in December 2013 when a Brazilian youngster we'll
call Telly proposed leveraging vim's language interop to add async.
The convoluted backdoor would proceed as:

- User code instantiates a python interpreter object which in turn
spawns a worker thread to play "Snake."  The thread uses vim's
python bindings to render ascii graphics into a buffer.

- Vim's main thread manages contemporaneous UI and "Snake" updates via
a newly introduced message queue that interleaves user keypresses and
status messages from the python thread.

An emacs bro will wonder why vim async should be predicated on an
external language that in turn would have to ostensibly support
threads.  There is a fork called emacs-ng ("new generation") that
follows a similar approach by first grafting a V8 runtime onto emacs
then declaring victory on multithreading.  But the project was founded
more as a gag than a proof of concept.  An emacs bro might further
wonder why it took more than twenty years for vim to contemplate
concurrency when emacs was peddling timer-triggered subroutines and
no-frills job control since jumpstreet (literally the kids-as-cops
procedural that premiered on Fox in 1987).

The answer lies in vim's through line that the OS is the one true IDE.
Perish the thought of a text editor encroaching on the OS's turf and
wrangling its own processes.  That was emacs's dumb thing.  If an
emacser wanted to incorporate logic written in a language that wasn't
elisp, he'd fork-exec a "call-process" of the third-party interpreter
like a total amateur.  To avoid such hamhanded measures, vim recruited
the heavy hitters from the lua, python, perl, ruby, and tcl camps to
cleanly embed their respective interpreters in vim's address space.
Emacs meanwhile recruited Julian Assange to do something less complicated.

So Telly (he of the convoluted backdoor multithreading proposal)
pitched his half-baked idea, then five days later begged off citing
Moolenaar's resistance to change, then a month later tried to revive
it, then another month later came round to Moolenaar's original
conclusion that it was kind of a lame idea.

But at some point during this two-month flirtation, Telly planted a
flagpole on the Github platform which by 2013 had become the default
forge for millennials but was not yet the default for the
rest of us.  It wouldn't be until the summer of 2015 that Moolenaar
was forced to migrate off Googlecode which was closing its doors.
Even then Bitbucket and Sourceforge presented compelling alternatives
to Github, and adopting git wasn't yet a fait accompli.  Vim until
that point was rocking Mercurial.

But while Moolenaar and the old guard were scouring for a port in the
storm, the youngsters had cottoned to Telly's rebel outpost.  In a
modern-day retelling of the Field of Dreams story, an unheralded
everyman is convinced by a disembodied voice that if he builds it on
Github, they will come.  Say what you will about the site's opacity.
With its slick web interface and reliably fast response times, Github
catalyzed reactions that Bitbucket and mailing lists could not.  The
site struck just the right balance in making git as simple as possible
but no simpler -- no mean feat.

Forks of well-known codebases by modestly skilled individuals
generally go nowhere or at best attract similarly unremarkable
journeymen.  But Telly had drilled into a gusher of pent-up desire for
change.  The initial flurry of commits contained several familiar
names.  They were the same kibitzers on the vim mailing list, guys who
had long been chomping at the bit to light up the floor if only
Moolenaar would let them.  Given a common rallying point, dudes were
now furiously rearchitecting vim with the no-holds abandon of
underemployed indoorsmen in their twenties.  It helped that neovim's
inception became a cause celebre on Hacker News, stoking the passions
of vim loyalists and malcontents alike, and reaffirming the chestnut that
there's no such thing as bad publicity.

Inscribed in Telly's initial commit were blueprints whose prescient
and uncannily specific recommendations could only be chalked up to
divine revelation.  When Telly came down from the mountain, he carried
not one but two tablets, one for libuv and the other luajit.  Only
twice in history has a heady project specification made good on its
promises.  The first was the founding of the United States.  The
second was neovim.  If Telly was neovim's Jeffersonian ideologue, then
the coder known as ZyX was its Madisonian brains.  It would be years
after neovim's founding before ZyX could fully flesh out Telly's
vision, but amazingly the integration of both libraries yielded
precisely the boffo benefits foretold.

Libuv factors out the control loop so that neovim programmers need
only focus on their added feature and not when nor how it feeds back
to the user.  This was Telly's original frustration when implementing
a multithreading proof-of-concept.  While the thrust of his proposal
was the backdoor python business, he had to learn, to his chagrin, the
details of vim's control loop in order to weave the new python
indications into the keypress stream.  By providing a comprehensive,
and more importantly battle-tested, event framework, libuv absolved
him and all future neovim devs of this burden.  Contrast this with
emacs's handmade control loop which relies on subroutine writers
sprinkling calls to "maybe_garbage_collect" and "maybe_quit" to prevent
emacs from getting stuck in a long-running function.  Or having to
remember to fence off redisplay by deactivating then activating input
peripherals.  These onerous gotchas horrify most programmers but make
perfect sense to a present-day RMS or equivalently a college sophomore
in 1992.

But neovim's ace in the hole is Luajit, aka the court magician who
with one wave of his wand suddenly imbues neovim with full-fledged lua
interop.  All neovimmers mark their calendars to periodically remind
us heathens that their beloved editor can be extended with lua.  But
Luajit does much more than the already impressive foreign function
interfacing (FFI) between neovim's C and lua corpora.  The "jit" in
Luajit refers to a runtime byte compiler which in turn defers to a
native compiler when a portion of code is repeated often enough.  This
will sound eerily familiar to emacs users who as of 2024 are still
oohing and aahing over a native elisp compiler introduced in 2022.

But putting aside bragging rights over who got there first, neovim's
lua integration possesses one overwhelming advantage.  All the magic
is tidily compartmentalized in a third-party, general-purpose library
called Luajit.  Conversely, elisp and emacs are attached at the hip.
Every couple weeks, some emacs malcontent will reraise the prospect of
supplanting elisp with an alternative extension language such as
Common Lisp.  These "change agents" who seek attention more than work
would be better served by neovim whose extension language is far more
modularized and separable than emacs's Siamese conjoining with elisp.
Emacs is more accurately described as "an elisp interpreter with text
editing primitives" than it is "a text editor that understands elisp."
There is no elisp runtime that is not emacs itself.  Its byte and
native compilers are homemade contraptions intertwined with emacs's
innards.

Neovim malcontents also like to dunk on lua (although not nearly as
aggressively as they do vimscript), and the neovim faq defends its
choice with reasons having nothing to do with the truth.  No, neovim
chose lua because Luajit was the most advanced runtime FFI in 2014
(and possibly also now in 2024).  At the time its sole author was putting
on final touches and proving one 10X programmer applying steady effort
beats a revolving cast of thousands, each one not entirely sure wtf
the idiot before him was trying to do.  That Telly also hailed from
Brazil, the home country of lua, increases the posterior likelihood of
the Luajit explanation (since a vimmer say from Belgium would be less
likely to have been aware of Luajit).  Another faq entry asks why neovim
is stuck on Lua 5.1 and again the faq muffs the answer.  The actual
reason is Luajit and its pinning to 5.1.

And your point is... My points are 1. there's no telling which
open-source initiatives will catch fire, and 2. the aggregate annual
investment in emacs and vim exceeds the GDP of most small countries.
As Travis Oliphant observed about one's text editor on the Lex Fridman
Podcast, "it's your life."  Big Tech realized early on that owning the
browser was important.  Clearly the VCs backing the Zed boys believe
the text editor can similarly drive and analyze traffic.  I'm not that
keen on knowing whether Alice prefers tabs over spaces, but someone at
Big Tech is, and I'd love to sell him that information.  Just as
Google paid Firefox a shit ton of cash to put their search engine
first, I can see a similar deal putting Github or GPT-4 first in
vim or emacs.