Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc)

A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.

It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!

Emacs does start fairly slowly, though, takes about 0.6 seconds.

1. Don't load too much at startup, use use-package's :defer keyword where ever it makes sense.

2. Set gc-cons-threshold to a very large value during initialisation and turn it back down again once everything's loaded. That said, most-positive-fixnum is probably overkill and I should look for a way to reliably set it to half of my PC's RAM.

A less important third way to reduce startup times would be to byte compile everything (possibly even the early-init.el, init.el, and custom.el files, although that does mean you need to recompile whenever you change anything), but that doesn't gain you much.

It's like saying that editor can have full AI support because it can send HTTP requests to an MCP server. But MCP server isn't the end of the problem, it's just a gateway to problems, just like LSP.

For example, jdtls is often times broken, clangd sometimes works, sometimes doesn't. Language servers for ruby are a pain to set up. Some time ago LSP for Dart/Flutter worked under vscode, but not in Vim, because Vim had different assumptions how files should be reported to the LSP. Sometimes is the fault of the server itself, but sometimes the editor isn't fully compatible with some particular LSP server's quirks. It's a mess.