Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance.

Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

Messy and simple are orthogonal characteristics. A terminal is simple in that cursor movement, colors and style are all the result of a bunch of escape sequences. Once you have a list of the escape sequences you want to parse or emit, implementing a terminal or an application targeting the terminal is not hard. It's messy because there are historically a bunch of different terminals that implement different escape sequences. It's not easy and it's not clean and beautiful, but it's still simple.

It's a bit weird to bring up scripting languages. The problem is that people want a customizable and scriptable editor. Solving that problem by providing a script language to its users is not overengineering, it's simply meeting a demand.

Looking at this, it uses some native facilities simply to setup a web browser view. Within that, it doesn't even use the built-in functionality of a browser to render the text you're editing, but resorts to custom rendering and layout using webgl. This isn't simple or clean. It's a convoluted waste of resources in that regard. Why not use one of the smaller cross-platform OpenGL wrappers?

Maybe it'll be a fine editor, but it's much more complex than it needs to be. I guess that because they set a "Web-compatible build artifact" as a goal on the roadmap, it makes sense, but is that really an interesting goal? What problems will be solved once the editor is a tab in Chrome?

What's the memory footprint of Terminal.app and vim + plug-ins?

On windows my current cygwin session with tmux and a single markdown document open in vim is about 25MB. Some of my chrome tabs (jira is the most complicated thing open) are nearing 200MB, somehow outlook is taking about 500MB and Visual Studio is eating many GB's.

It's extraordinary how wasteful some apps can be.

Not sure, but I have had vim lock up my MacBook Pro with 16GB of RAM and force me to do a hard reboot

That sounds like an OS/hardware problem, honestly. There's no reason vim with any setup should lock up a machine.

The linter was the issue.

I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case.

If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.

Agreed, if anything will slog a text editor it is usually the linter

Also, you can choke vim with large (>5gb) test files. Or is that fixed now?

The irony is that sublime text doesn’t slog down

Sublime Text and TextMate will both choke big time if you feed them a large enough file without any line breaks. I have some largish machine-generated (5-10 MB) JavaScript data files that will reliably bring either editor to its knees if I accidentally click on one of them. The XCode editor also chokes.

I seem to recall (though haven't tried it for a while) that the Visual Studio Code editor handles them okay.

It's not a big issue -- since these are machine-generated, it's not normally necessary to edit them by hand. Every once in a while, though, I'll accidentally click on one of them in the file tree. Then I'll curse and kill the editor process.

Switch syntastic for ale: https://github.com/w0rp/ale It's asynchronous if you're running vim8+

Awesome, thanks for this!

Editing large pieces of text efficiently is a Hard Problem, especially collaboratively without conflicts.

In the case of editors like Xi and XRay, they use CRDTs, which doesn't look anything like how Notepad would represent text.

There's real work here that's actually useful, it's not just "another extensible text editor".

I have never, even once, in my nearly-20-year career had the desire to collaboratively edit a single, specific text file.

Isn't collaboration without conflicts what version control systems are made to do?

I even think it would be annoying if someone would just move cursor around when I edit something. And there definitely would be conflicts if they would try to edit the file at the same time. Who needs this feature?

The way it generally works is that each user has their own cursor.

Google Docs gives everyone their own cursors

Proof by personal experience isn't all that convincing. Maybe you've never done pair programming, but other people have.

If you really need to collaborate on the same file, can't you just share a session in tmux?

See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.

>> Does the world really need another extensible text editor?

People said that when Sublime was released

If you edit files once in a blue moon, `notepad.exe` is more than sufficient.

If you work with hundreds of files per day as part of your profession, you are going to want something a bit better. I wouldn't call it over engineering if it solves a real problem.

By the way, Notepad cannot display files with unix-style line ending, it doesn't keep indentation and it inserts BOM when saving file as utf-8.

It also has 1 level of undo.

You may be committed to dying on this hill, but keep in mind that corpses left behind stink up the place. Please have a care.

> How disappointing that text editors require such... abstraction.

Why would you think there's no need for sophistication in text editors? They're used to do a lot of complicated things.

Let's see if someone able to code complex application only using Notepad.

As of 2007, Arthur Whitney was developing k [0] and kdb [1] in notepad [2].

[0]: http://kparc.com/

[1]: https://kx.com/

[2]: http://archive.vector.org.uk/art10501320

It's better than Edlin. That was my first text editor.

My first editor was a keypunch.

I don't remember keypunches being very amenable to editing in any sense of the word. That was a long time ago though.

Take a look at vim/emacs. They are anything but simple.