Vim after Bram: a core maintainer on how they've kept it going | Hacker News Reader

Vim after Bram: a core maintainer on how they've kept it going

thenewstack.io

228 pointsMilnerRoute92 comments

I've been using vim for 20+ years and it's been fantastically stable software for me. I have never cared about what version I am using because I've never needed to. An exception to this is that I'm now accustomed to using `:term` which came with vim 8.0 (2016?).

I think it's silly when colleagues point out that VS Code has vim bindings. The bindings are what I know and enjoy, but they're only half the point. I like to work with the machine, in the terminal. I don't like my text editor being a browser that pings M$, and will end up doing so again, eventually, even after I have to search up(!) how to disable it.

There's a lot of value in moving slow and not breaking things. I'm glad there are maintainers willing to carry that spirit forward.

I only notice vim 9.0 because it highlights as you search. Otherwise I'm in total agreement.

“:set hlsearch” in pretty much any version of vim. (I don't know if vim 9.0 changed the default or not.)

No, it didn't. Vim rarely changes defaults, if at all, but it can add settings to example rc files.

That's very odd, then... I definitely remember hlsearch being off in Vim 8, and on in Vim 9.

Either way thank you! Now I have even less reason to notice.

Probably distro-specific, so up to package maintainers.

Note that some Linux distros provide their own versions of vimrc that overrides the upstream default settings. Note also that newer Vim versions come with a "defaults.vim" that you can load if you want, containing arguably sensible inoffensive defaults; if you or your distro loaded that, it might contain hlsearch as well.

Vim did that in 1994 already.

I didn't find that feature to be that handy tbh. Mostly because it necessitates me to search for the pattern manually. What I usually want in my workflow is to highlight the word under the cursor automatically. This simplifies the code reading significantly for me and I am not aware of such Vim feature baked in?

Luckily it's very easy to add one, e.g.

  function! HighlightWordUnderCursor()
      if getline(".")[col(".")-1] !~# '[[:punct:][:blank:]]'
          exec 'match' 'Search' '/\V\<'.expand('<cword>').'\>/'
      else
          match none
      endif
  endfunction
  autocmd! CursorHold,CursorHoldI * call HighlightWordUnderCursor()

Or, a stupid way: “#*” Or, also stupid: “*``”

I'm right there with you on using :term. I also do a lot of work on console only tty's without X or gui environments and splitting between code/text and term is very handy.

Few years ago I reported that I can't put a character in the most bottom-right corner when setting my own statusline. Bram responded that this was intentional, as some (presumably already ancient) terminal emulators had problems with this.

I can probably take the vimrc and workflow I had for Vim 6 back in ~2000 and use it in the latest Vim without any changes or problems.

And look, if VS Code or whatever works better for some people: great! Fantastic that works for you! But for me, the dedication to compatibility and not breaking existing use cases is something I've really come to appreciate, even though it's a slight annoyance at times.

Beyond personal preferences i think there's great value in having tools that are that stable around.

There are plenty of legacy systems around that needs to be maintained and if you can use an efficient and familiar tool that still works in that context that should help such use cases greatly.

If it's ancient, it's not an existing use case, so you just get the annoyance part

How do you know no one is using it?

(perhaps "ancient" was a bit of an exaggeration by the way; "old" is probably better).

Obxkcd: <https://xkcd.com/1172/>

Wow thanks for that tip! I wasn't aware of :term before but that's great. I have always used :!sh or ^z.

I have to say as someone in tech, one of my "personal embarrassments" is that I still only know how to use vim on a basic level. I often see my coworkers flying through our codebases in their custom vim/nvim setups and I gotta say I get a bit jealous.

But every time I think about learning vim I always go back to the argument that it's just a tool to get a job done and right now, I'm very good with one particular tool (vscode) and between my dayjob and other responsibilities I just can't justify the time sink to learn vim to a level where I can be "professionally productive". For now I mainly use it for git and the occasional markdown document I need to create on the fly

But beyond that I really admire vim and nvmim. The fact that my coworkers can use a 30 year old text editor and extend it to support the latest and greatest LLM's and language servers is just mental to me.

I hope Bram is up in heaven right now, teaching god how to quit vim.

As someone who used VS Code for many years and before that PyCharm, it only took me a couple of weeks to regain full "professional productivity" after switching to Neovim. But it will take me years to master Vim.

For anyone that wants to learn Vim I really recommend “practical Vim” [1] .

It’s a fantastic book that really gets into developing the right mindset to use it. It´s great once you “get it”, but it’s a different concept from the rest of text editors. Once you learn the basics, you’ll do great advancements in little time.

To me, it’s the best tech book that’s I’ve read. It’s really that good.

[1] https://pragprog.com/titles/dnvim2/practical-vim-second-edit...

`vimtutor` is also excellent and most folks either already have it or can get it in the next few minutes.

I'm similarly embarrassed about only knowing vim on a basic level, but I've actually been using it as my main editor for programming for close to 20 years. I still navigate using arrow keys, for example. After years of tweaking, I now use nvim with the default config and I'm pretty happy with the minimalism. Despite only having very basic knowledge, I'm still more comfortable in vim than most other editors. Only the recent wave of AI assistants is getting me to use it less often.

There’s nothing wrong with arrow keys, Esc or mouse. Using Vim doesn’t mean you have to buy into elitist pianism. Personally I don’t care about typing speed because I map, abbr and snippet code “to death”. All I want is to free my mind (not hands) from mundane work as much as possible and h vs left arrow doesn’t help with that at all. I don’t even land on homerow when I take the keyboard. It’s more like qwed kop' and changing.

I highly recommend the VSVim extension for VSCode. There’s no need to dive into the overwhelming world of customizing vim. You can get all the benefits of modal editing in your existing editor. In fact VSCode is even better with its built-in multi-cursor support.

There is no such thing as "Vim as an extension." I've tried so many different Vim extensions in different editors, IDEs, web browsers, etc. None of them are without some glaring deficiencies, big and tiny annoyances. With perhaps the only exception - Evil mode in Emacs feels like a built-in thing; you forget that it's an afterthought, an extension. It works as if it was designed to have it from the get-go.

Yet, I agree, if you must use VSCode, IntelliJ, Sublime, Emacs, etc. - you don't have to unlearn your vim skills. What's great about vimming - it's like riding a bike, you learn it once, you can do it anywhere.

Eh. I use vim. I like vim. But what matters is that you have a tool that works. If that's vscode, and you're okay with that being your tool[0] then there's nothing wrong with that.

[0] I personally wouldn't like to be tied to a tool that phones home to and is by Microsoft, but plenty of people don't care; so long as it's an informed choice that's completely legitimate.

I learned both Emacs and Vim (VIM for its speed, and emacs for its versatility). As a commenter pointed out, it’s all about freeing the mind. When you’re sure that an action is going to get a specific result, you can just do it and not think about doing it. While I can do most basic actions in whatever editor, there are workflows that are only possible in Vim/Emacs. One example is switching effortlessly between writing code, testing it, fixing it, managing the files, versionning them. Not a speed boost, but a flow boost.

> every time I think about learning vim I always go back to the argument that it's just a tool to get a job done

Tools are tools; their value is not so much with the features they carry but with our abilities to utilize them with joy. If someone perfects their workflows using notepad.exe, telling them something is wrong with that is like forcing a grown-up to "eat properly" even though they've been holding their spoon since childhood in their left hand, like a pencil.

If you try, however, to focus not on the tools themselves but the big ideas they convey, that might change your perspective on many things. At some point, after many cycles of frustration, amazement, inspiration, and awe, you will learn to appreciate certain ideas.

You are right to admire Vim - its main idea of modality is a wonderful, beautiful, powerful, and pragmatic model. I, for example, even though these days rarely use Neovim itself, consider myself "a diehard vimmer". I use that model everywhere - in my terminal, my editor, my browser, system-wide - with my window manager. For example, I control the volume, playback, and speed of my videos and my music with home-row keys. The incredible instinct and dexterity one can build over time can be mind-blowing. It's not about "building a discipline to not touch the mouse or arrow keys"; it's about realization that you can do without them - "do not try to bend the spoon...", etc.

Some other tools also exhibit the use of great ideas. Emacs builds on the cornerstone of a different, yet incredibly powerful idea - the idea of practical notation for lambda calculus, which is known as Lisp. Lisp probably can be crowned as one of the most important ideas in computer science. Understanding it makes it hard to think of anything more influential than Lisp. Any programmer who dismisses the idea of Lisp based on one concrete implementation of it is misguided.

VSCode carries the idea of an editor built on top of a browser, which turns out to be not so bad of an idea, after all. Cursor - the idea of tight LLMs integration, etc. And it's not just the editors and IDEs; take any of these and you find some beautiful ideas behind them - Unix, Git, Make, Jupyter, React, Docker, SQLite, Org-mode, etc. Each of these tools embodies a fundamental idea that has proven influential and valuable in computing.

Borrow good ideas, try them, practice them, implement them into your life, expand upon them. Understanding the core of the ideas is empowering. And often it liberates you from the burden of specific implementations - i.e., you don't have to use Neovim to appreciate the idea of Vim.

There is often an implied criticism of "if its not under active development for features, its not good" - which I don't agree with (and obviously neither do the VIM maintainers I think)

Maintenance mode is a good place to be IMO. I don't think anyone looking at a codebase with this maturity should feel "why aren't there significant new feature updates".

Wayland, ok I can see there are things which need 'bring into the modern era' but I don't think either Wayland, or XDG represents a massive about-face or fork moment. (I don't use graphically aided editors either vi or emacs, I live in terminal emulated space)

The moment of fear is when it ceases to be brought into current packaging by the distributions which re-factor it. I don't see any sign of that happening either.

Definitely true, probably of almost everything.

Rarely the case, and rarely acknowledged, but almost everything is a tool. If everything followed the Unix principle rather than trying to constantly grow and pivot, we would have a lot more solutions that just work.

The more often people think about things as tools under the Unix principle, the (generally) less user hostile they are.

I love vim and I’m happy Chris stepped in to save the project, his vim CSV plugin is something I use daily. Though I really hope vim and neovim merge, I don’t see a reason for the two projects to stay separate.

I have had similar thoughts, and have even theorized that the two would merge at some point. But that said, The goals of the two projects are still pretty different. It sounds like Vim proper is going to start receiving More new features, but overall it still has a significant focus on stability. I do wonder if that will shift as the new maintainers get more and more confident and capable in the code base. Once that occurs, I suspect that neovim will start to look really good, even perhaps including to the vim proper maintainers.

What might be a big difference though and a big enough stumbling block to prevent merging is the fact that neovim code base has been refactored extensively and updated. Having worked in a big project that was refactored without me, and then returned, it is actually worse than a new code base because you feel like you should know where things are, but they aren't there. It continually misleads you and wastes your time. I could see that frustration being enough to keep the them proper people from merging or moving to neovim.

Given what he's saying here -- that Vim is in "maintenance mode" -- I don't think you'll need any formal merge. Neovim is just where all new development is done, and it'll slowly replace traditional Vim over time.

I'm not sure admins of old mainframes from the 80s would be interested in getting latest vim running on their hosts! I still use whatever old version of vim that came with my freenas.

I mean, sure. But like, vim never merged with vi, either -- to this day, you can find old things that are still running pre-vim versions of vi. It's just that over time, more and more things switched their default version of vi to vim, just as over time, more and more things will switch their default version of vim to neovim.

vi != vim

> I'm not sure admins of old mainframes from the 80s would be interested in getting latest vim running on their hosts!

I doubt many 1980s mainframes were ever capable of running vim. People on 80s mainframes generally used mainframe text editors such as ISPF Edit (on MVS) or XEDIT (on VM/CMS)

Vim’s makefile does have support in it for compiling on Amdahl UTS, Amdahl’s Unix port for IBM-compatible mainframes, and so possibly vim could have run on an 80s mainframe running UTS. However, I’m sceptical there are any mainframes left running UTS anywhere on this planet-nobody uses it in production any more (apparently the last production users were some US telcos in the first decade of this century). I doubt any of the small number of still-working 80s/90s IBM(-compatible) mainframe systems in hobbyist or museum hands run it. There is a version available online you can run in an emulator, but it is an ancient version from the 1970s, whereas I believe the vim port is to a newer 1990s version-and I don’t believe any of those newer UTS versions are publicly available-either they survive in some private collection, or they’ve already been lost to the sands of time.

> Neovim is just where all new development is done, and it'll slowly replace traditional Vim over time.

Nailed it. Bram made the decision on his own and vim's fate is stuck with it. I was bitter about it but now I think it's best for both communities.

"replace" ha ha!

Not likely. The directions for the projects seem pretty distinct.

It should be noted that some original vi are still installed by default when installing some OSs.

The whole idea that a project needs to be in constant new-feature mode is just not reality. Just as one example: I'm still using the fluxbox desktop (about 25 years now), and it still meets my top level GUI needs for interacting with my workstation. I don't really _want_ it to change. I want the UI to be exactly the same after an update, so as not to disrupt my workflow.

Yep. It's not that text editing changed much since <yearnumber>. And the more years passed, the less there is to "feature". Projects with constant new features after many years of development demonstrably don't know what they need and how to let themselves pause and reflect.

It is extremely likely that the default distribution of vimwill be neovim and not vim after a decade.

Just like vim replaced vi, neovim will gradually replace vim. Being maintenance-mode software means only greybeards (and some stubborn holdouts) will stick to it over time and as greybeards retire, the new maintainers of linux distributions who are more familiar with neovim will make their choice.

Vim and nvim are different and have different goals. One is for people that enjoy Lua, the other is vim.

Or it will meet the issues all "new development" projects meet and live through its first crises. Cause having new features comes at a cost, and people eventually grow tired of costs they can't just throw money at.

I am a long-time vim user and haven't had time to watch neovim developments more closely. What would be the incentive to move to Neovim, e.g. what are its best-selling features that vim doesn't have? Genuine question.

It's 'native' LSP for me. I have coc.nvim in Vim and it's great, but it depends on nodejs. Tree-sitter is another good one, although in my experience it might increase CPU usage noticeably.

I usually only have LSP for a single language so coc is not of much use for me. Syntax highlighting rendering engine in vim OTOH could use some speed improvements. I see it drowning sometimes on larger files with sematic syntax highlighting.

For me it's Tree-sitter support. It builds a syntax tree for your files incredibly fast and allows the editor to use it for various things, including much better syntax highlighting.

https://tree-sitter.github.io/tree-sitter/

I do not believe that is possible without compromising the goals of one of the two projects.

Vim is expected to continue to work everywhere, even on some bank's circa 1980 mainframe. NeoVIM has become an effort to revitalize the project. Support for ancient systems was tossed almost immediately (eg no more 8.3 filename support code). NeoVIM also included some much improved default configuration values.

> even on some bank's circa 1980 mainframe

Continuity I get, but how much are we collectively burdened by having a few ancient uses determine the wants of the many?

Our window of compatibility only seems to grow larger over time. Old systems mostly get replaced when they lose function or the replacement becomes cheaper. But the replacement usually expects to last slightly longer than what its replacing. We've seen this slowly creep up in home computers, phones and even servers. I would argue that this is a function of small incremental improvements in everything from hard drives to computing.

Lots of designs from the past can no longer connect to the internet in a meaningfull capacity but new hardware today might meaningfully last far longer than the developers could even anticipate.

I wonder about that, too. Not that anyone's beating my door down to port my own projects to zOS or anything, but I consider modern Linux/BSD to be my baseline target for all new code I write. If it runs well on amd64/aarch64 Linux, Mac, and {Free,Open}BSD, that's enough. Well, and Windows, if someone makes it run there and it's not onerous to support. I wouldn't accept patches that make it harder to build or maintain on those primary systems.

It's not that I actively hate anything that isn't a recent 64-bit Unix, but that the people on other systems are either 1) hobbyists who are competent to port stuff to their own systems, or 2) companies who aren't paying me for extraordinary support.

Bummer if something I wrote last week doesn't run on HP-UX, but it's not going to cost me sleep.

I had to think long and hard about whether to accept a PR that fixed ppcle64 support on the library I maintain. Since it wasn't too much of a diff, I accepted it, but in many other situations I wouldn't.

If it’s trivial with zero adverse affects on common hardware, fine. If it adds the equivalent of a bunch of ifdefs or requires adding autoconf, nah.

At this point, between WSL2 and how good wine has gotten, there's a lot of crossover for building/maintaining, outside the target OS

> Continuity I get, but how much are we collectively burdened by having a few ancient uses determine the wants of the many?

Because of neovim and the power of forking, essentially nothing. The ones who favor stability choose one program, the ones who favor bleeding-edge chooses another that matches.

Vim is also POSIX-compliant (or very close, with compatibility options, on a POSIX platform). Neovim doesn't have that goal.

If you want POSIX compliant, better to install a proper vi. Normal Vim is extremely not POSIX compliant, and I wager 100.00% (rounded to the significant digits) of Vim users don't know, use, or want POSIX compliance. You lose a lot of features you would consider to be basic.

Also you probably want ed (the standard text editor) for POSIX compliance. (Fun fact, vi is not required by POSIX, so you will not find it on every single POSIX compliant host.)

"... vim and neovim merge,..."

This seems very unlikely. In neovim help docs there's a paragraph in file `nvim.txt`

   Nvim is emphatically a fork of Vim, not a clone:
   compatibility with Vim (especially editor and Vimscript
   features) is maintained where possible. See |vim
   differences| for the complete reference of differencesfrom
   Vim.

nvim maintainers believe the project diverged and compatibility is best effort at this stage. Essentially, there's no plan to merge the two projects at this stage and the benefits are not evident.

> Though I really hope vim and neovim merge

I hope that if they do merge that the connection to ICCF Holland is maintained.

Every time you start vim (without specifying a file) you see the message "Help poor children in Uganda!". It's been a salutary thing over the years to see Bram building something as amazing as vim and maintaining the commitment to helping orphaned kids in Uganda, I would be sad if that disappeared under the neovim bus.

If you're a vim user and you'd like to support Bram's vision, here's the link https://iccf-holland.org/donate.html .

Related: The State of Vim, 200 comments https://news.ycombinator.com/item?id=42810176

Didn’t know “the” core maintainer of vim has passed. But very nice to hear community has rallied to keep the project alive despite losing such a key person.

In the race to incorporate AI in everything, it has turned me away from tools such as VSCode, IntelliJ. Instead have reverted to use of vim/nvim, setting up my own development environment, customizing it to my liking with desired mappings, and enhancing with plugins on an as needed basis.

Even with all of my customizations, code completion is still snappy (since it’s lazily loaded), and I do feel more productive compared to GUI editors.

Only downside is collaboration with coworkers that have always learned to use a GUI editors. In those cases I just open up whatever text editor corp uses (most cases it’s just vscode).

Although for co-workers I dislike, I do love to see them struggle to use vim.

Fwiw: 'Bram Moolenaar has died', https://news.ycombinator.com/item?id=37011324

The last sentence is savage and as a fellow long time vim user, I like it. :)

A long time ago I used an editor called Origami. It had really great folding.

After trying to replicate that exact folding method in many editors, the only editor that did it is vim with the kent extensions.

So... Thank you Bram and thank you to those who made the kent extensions.

https://github.com/vim-scripts/Kent-Vim-Extensions

Hate to say it but when Bram died all the energy seemed to go to Neovim. It seemed for years Neovim was just the weird fork, now it actually feels like the new Vim. And Neovim is really nice, especially with stuff like Treesitter, Mason, and the distros (I use Lazyvim myself).

https://lwn.net/Articles/1002342/

LWN coverage of what I'm guessing is the same talk.

My usual comment on any thread touching vim, as an answer to all hypothetical comments talking about how vim never clicked :

Remap the Escape key to CapsLock else you will never like vim (provided you are a normal person)

It's the most important key and you should punctuate all your inserts with it. So it'd better not be the key that's the furthest away from your fingers. The reason that's the case is an historical accident.

Don't be a victim. Remap.

P.S : Yes, I know about people using Ctrl+[, or Ctrl+C, I know you got used to it but one gets used to anything, it does not mean it's good. A weird combination isn't great and Ctrl + C has some quirks --> https://vi.stackexchange.com/questions/25764/use-control-c-i...

P.P.S : Yes, I know about `jk` it's clever ok but my mapping is system-wide and now I enjoy Escape being at the right spot for bash, zsh, fish, gdb, firenvim vim modes at no configuration cost.

As a Caps -> Ctrl lifer - i feel personally attacked.

As an aside; if you do the mapping system wide - it's useful everywhere - caps lock is useless everywhere, and Escape is marginally usefull in general desktop usage. I do ctrl-a-ctrl-a tmux 100x/day to swap panes; and ctrl-u in terminal countless times. Minimizing finger movement on all the little things is valuable. That said; I've also become a fan of home row mods also.

For 100x caps lock is an unergonomic position with a sideways pinky move. Much better to move it near space to a thumb (home rows is another alternative, but harder to set up)

Please don't feel attacked. At least with Ctrl there, the combination is less awkward. My point is that vim is dumb is you don't use some workaround around the problem and most people don't talk about it and just tell you that vim is great and then wonder why it's niche.

I've been a Caps -> Escape-er for years now. Recently, as I've moved to Walyand and KDE Plasma, I saw that their advanced settings support Caps -> Esc / Ctrl: Esc when pressed, Ctl when held. I've been considering it, especially since I recently broke and replaced my Ctrl key. Inertia holds me back, but I had the same concern before Caps -> Esc.

This project is just like the program: people can't seem to quit.

Neuralink or something is needed to make keybindings unnecessary. Computer, delete this paragraph. computer move to next function. Computer replace this word.

It's called a keyboard and muscle memory.

Still, it's nice to think about a future where Brain-Computer Interfaces are advanced enough that you could feasibly write code while leaning on your elbows with your chin tucked into your palms. Of course you'd still be staring into a large mass of Java 8...

And companies will then force you to watch ads while you sleep. No thanks.

it requires training and thus is expensive

ha ha! That's really funny 8-) Not sarcastically, actually entertaining 8-)

I had to upvote, even though I totally disagree, just because it made me laugh out loud (not lol, actually laughing, you know, like when noise comes out of your mouth)

I've been saying for years, that as soon as the matrix spinal tap was available, people would be lined up to get it.

Reality is so boomer! Who wants to remember things when we can immerse ourselves in our pure make-believe identity. 8-)

I really really am so glad I grew up before internet brain damage destroyed the concept of individual autonomy.

they say one needs to grok vim language, but for most of the world it's foreign language. After 20 years I still don't known what "yank" means, dictionary explanation is obscure. I think it's the reason Vim is popular in West but not East (I mean Eastern Europe).

> Who wants to remember things when we can immerse ourselves in our pure make-believe identity. 8-)

Some people already live this (see dissociative identity disorder)

Computer, delete this paragraph. computer move to next function. Computer replace this word.

dap /^fu cw

Seriously?

imagine I'm not thinking in English, so interface without translation layer will be faster.

Exactly. People think that vimmers type with fingers, where in fact "typing" really happens in the brain. Ask any seasoned vimmer immediately after a typed sequence what keys did they just press, and most of them would struggle to "spell out" the sequence, even though they would have no problem repeating it again on the keyboard.

The mechanics of "procedural memory" (or as commonly called "muscle memory") is a complex, still not-well understood topic. We still years away from understanding how brain converts conscious actions into automated motor programs. BCIs (brain-computer interfaces) like Neuralink, even though can feel amazing, still can't artificially replicate true procedural memory formation.

As long as the keyboard input remains relevant, vim-model will remain the most ergonomic, fastest, attainable and pragmatic model for text-editing and navigation.

> Maintaining VIM turned out to be a full time job, though the community has stepped in to help.

I think if you sneakily put me on Vim 7.5, I might not notice.

recently started to use vscode a bit due to ai stuff, vim's copilot works but vscode is better in that regard,now i use both

vim is stable and consistent. I vendor what plugins I do use with git submodules and everything just works for years and years.

LSP integration works as well as a given language engine has implemented it. I’ve got an autocmd group that automatically binds keys if that language’s corresponding LSP compiler is on my system. So with something like Rust or Go, I open the file and just go (no pun intended).

When I am trying out a new language, I just add a few configuration lines to my vimrc and all the bindings work automatically.

For non-LSP langs (or those with heavy servers) I use good ol’ ctags and grep, which is my preference anyway.

vim has been rock-solid for a while now and I can count on it not to break (or to break my configs!). I think very carefully about my workflows over time and deliberately configure the editor for exactly how I actually use it.

Anyone who doesn't use Vim is just evil in my eyes, I mean, come on! It's the best thing ever.

Reaching for the escape key with your left pinkie while trying to keep your fingers on the home row hundreds of times a day in order not to have to dislocate your right pinkie to reach the arrows is is the idea of the century

Snark apart, praising vim without mentioning escape key remapping is criminal imho

To each their own, but to me the only key easier to hit than the Escape key is the space bar, and returning to the home row is like a 20ms move. On the other hand, if you're actually using control keys in the (now standard) lower left and lower positions, then we're just on different planets. :)

I don't remap; I use ^[.

I heard that IBM got the PC keyboard positioning wrong. You can remap this in both macOS and Windows and Linux so its not a big deal anymore. Use Esc<->Capslock and have a gentle vim/neovim existence.

> Anyone who doesn't use Vim is just evil in my eye

Hehe. Evil users are vimmers. Evil stands for - Extensible vi layer for Emacs. Try Emacs for a while, and you may realize - Emacs can vim better than Neovim.

Reply on news.ycombinator.com