Hacker News Reader

Comment by tomc1985 | Hacker News Reader

tomc1985

How disappointing that text editors require such... abstraction. Overengineering at its finest?

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?

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

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!

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.

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?

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.

> 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.

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.

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

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

Reply on news.ycombinator.com