Very cool. I thought Nano would perform much better..?
A problem with some fast editors might be ease of use. For instance, I would have loved to try out JOE editor, but I couldn't find builds, the code is hosted on Sourceforge, etc. etc.
I think a huge feature for an editor is usability: is there a website where I can download a build for my OS? Does it update by itself? Is it easy to configure, install plugins, etc.?
I agree with you about a package manager being a good OS feature, but this is unnecessary snark when the two most popular operating systems don't come with a package manager (of this sort, at least).
Joke aside, that didn't install a Windows program, and I'm willing to bet the WSL wasn't installed by default either, and I'll also bet that didn't work in a Windows command prompt.
Well that is sort of like saying Emacs is written in Elisp. Its true a good portion of the editors are written in their own scripting language (js for atom, and elisp for emacs, and beanshell for jedit) but I believe the critical components that these tests test for are probably not.
Right, i guess that was my point as well. The java factor probably doesn't play into the core speed. I would imagine the rendering is what screws the performance for the js based editors.
Of course I know they load up a web browser but you would think that is something what Java people would do (in terms of over engineering and over use frameworks and fair game as I'm a Java developer).
I'm basing this on the original poster that thought it was funny that Emacs is fast/small. You don't think its ironic that a Java editor is small and fast given its history of being slow and bloated?
I ask as a recent convert to VSCode. Had spent about 18 months on ST3, and about a decade on Sublime Text 2 before that, as my daily / primary editor. Never going back.
It's open source, and free, and has a superset of Sublime's abilities (for my use cases anyway).
It's been all upside, and thanks to keyboard binding import, the upgrade cost me maybe an hour total during the 1st week. IOW a ~frictionless transition.
The catalyst was annoyance w/ an ST3 plugin for Tern (tern_for_sublime). VSC ships OOB w/ things like nice autocomplete for TS and JS, and it imported all my ST3 keybindings, and I haven't found anything I want to change that's not a trivial user config option.
I really wanted to give Atom a chance since it gets stuff like ligatures right, but I find its slow startup speed to be a no-go. I simply find in Sublime a much stabler experience and faster startup time, which makes it feel more productive.
I was very pro-Atom for a while. I've since packed up and moved to Vim and then on to Emacs with evil-mode.
I never had any performance complaints while I was actually using Atom, but a while back I made a mistake when generating a text file that turned out to be ~1.5GB. Luckily, it was just one mistake in the footer, so I could take care of it without regenerating the entire thing.
Without even thinking about it, I opened it up with Emacs, went to the bottom, made my changes, and got back out. About a minute later, I saw how large of a file it was and was suddenly even more impressed with Emacs than I had been.
Just for fun, I then tried to edit it with Atom. Nope.
ligatures in source code? It seems as soon as I use a non-fixed width font, then indenting and other code formatting becomes tricky. Bjarne Stroustrup uses a proportional spaced font in his C++ book and I hate it.
Okay then ... does look good ... I assume that normal ascii is used under the hood and that is what the lexical analyzer sees. I am open minded -- of course it has to work with emacs -- I am not that open minded ;)
It's just a font, the underlying text is still the same no matter what font you use to render it. In fact, you could set Fira Code (or Hasklig) as the font for your terminal and (as long as your terminal app can render ligatures) it would render in emacs or any terminal-based editor.
I can get behind it on my *nix systems, where I find it fast enough, but I find it terrible on Windows, especially when it updates and I find myself with two versions.
Approaching the subject another way, Pavel Fatin's excellent article Typing with Pleasure (https://pavelfatin.com/typing-with-pleasure/) goes really (really) deep into another way in which text editor performance can be compared
With 'zero-latency typing' enabled (which it is by default on current versions), IntelliJ rates well on typing lag comparisons which are probably the most consequent metric for 'feel'.
I've always had problems with IntelliJ IDEA feeling extremely slow and have never been able to figure out why. The mouse cursor even skips when it's doing anything intensive. This is on a machine with 4 cores @ 3.2GHz and 16GB of RAM. VSCode seems much faster.
I'm sure many editors there have changed since then. This is true of Visual Studio Code, at least - the tests uses 1.4, way behind the current 1.14. I know the team has been spending some time doing performance improvements (e.g.
1.9 had some big improvements in highlight performance[1]) and I wonder how it compares.
Oh man I forgot about JED!
It was my first editor. At the time Emacs was often too slow on my computer (circa 1995 maybe even as early as 93).
That editor was awesome and it had a cool library I think called Slang which had its own sort of ncurses implementation and scripting language (probably wrong on the details).
The author also implemented an awesome news reader back you know when people used news readers.
I'm actually sort of impressed how well JEdit performed. Other than micro its one of the only not written in a C/C++ language (the critical components... I realize emacs, code, atom, sublime all have their extension languages).
Java virtual machines generate very efficient machine code nowadays, especially for an older codebase like jEdit's that is not particularly "object oriented".
I think it should count. Emacs might come from a different time but it's plenty user friendly for a text editor, it even has graphical menus and a package manager. What more do you want?
I was moved to try Emacs with my own test file and (somewhat to my surprise - it's normally pretty crap with long lines) it had no problem loading a 3GByte file consisting of 3,000,000 1K lines.
For short lines it's generally fine. I've never had a problem working with multi-GByte log files with 100-chars per line or so.
(Even if it's OK for text, you are probably best off avoiding very large source files - some of the major modes seem to be written assuming <100K files and/or short lines. Python mode in particular seems to bog down very easily. C mode is fine for editing, but large-scale reindents can get pretty slow. And so on.)
I guess the focus on large files has it's certainly useful in certain cases like viewing log files, data dumps, etc... but for the most part I find myself opening many many small files with less than a couple hundred lines each.
We need tools that focus on application development needs, not text editing.
71 comments
[ 4.8 ms ] story [ 132 ms ] threadA problem with some fast editors might be ease of use. For instance, I would have loved to try out JOE editor, but I couldn't find builds, the code is hosted on Sourceforge, etc. etc.
I think a huge feature for an editor is usability: is there a website where I can download a build for my OS? Does it update by itself? Is it easy to configure, install plugins, etc.?
Thanks.
I'm basing this on the original poster that thought it was funny that Emacs is fast/small. You don't think its ironic that a Java editor is small and fast given its history of being slow and bloated?
Not that surprising...
I ask as a recent convert to VSCode. Had spent about 18 months on ST3, and about a decade on Sublime Text 2 before that, as my daily / primary editor. Never going back.
It's been all upside, and thanks to keyboard binding import, the upgrade cost me maybe an hour total during the 1st week. IOW a ~frictionless transition.
The catalyst was annoyance w/ an ST3 plugin for Tern (tern_for_sublime). VSC ships OOB w/ things like nice autocomplete for TS and JS, and it imported all my ST3 keybindings, and I haven't found anything I want to change that's not a trivial user config option.
I never had any performance complaints while I was actually using Atom, but a while back I made a mistake when generating a text file that turned out to be ~1.5GB. Luckily, it was just one mistake in the footer, so I could take care of it without regenerating the entire thing.
Without even thinking about it, I opened it up with Emacs, went to the bottom, made my changes, and got back out. About a minute later, I saw how large of a file it was and was suddenly even more impressed with Emacs than I had been.
Just for fun, I then tried to edit it with Atom. Nope.
[0] HN discussion: https://news.ycombinator.com/item?id=14821446
[0] https://news.ycombinator.com/item?id=14821446
[0]: https://github.com/i-tu/Hasklig
The most amazing part of this is the JOE editor. Performance and memory aside, I'm astounded it has been maintained by the same person since 1988! [2]
[1]: https://danluu.com/term-latency/ [2]: http://joe-editor.sourceforge.net/
That unsurprisingly quite critical and surprisingly variable -
https://pavelfatin.com/typing-with-pleasure/#input-latency
I'm sure many editors there have changed since then. This is true of Visual Studio Code, at least - the tests uses 1.4, way behind the current 1.14. I know the team has been spending some time doing performance improvements (e.g. 1.9 had some big improvements in highlight performance[1]) and I wonder how it compares.
1: https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
That editor was awesome and it had a cool library I think called Slang which had its own sort of ncurses implementation and scripting language (probably wrong on the details).
The author also implemented an awesome news reader back you know when people used news readers.
Recalls to mind that old joke, "Eight Megs And Constantly Swapping."
Suggestion: previous submission should be at least a year old before rehashing is allowed
But having the same links resurface over and over doesn't seem optimal to me.
I'm gonna throw out the idea that it should show the number of exact url results right there without having to click it.
For short lines it's generally fine. I've never had a problem working with multi-GByte log files with 100-chars per line or so.
(Even if it's OK for text, you are probably best off avoiding very large source files - some of the major modes seem to be written assuming <100K files and/or short lines. Python mode in particular seems to bog down very easily. C mode is fine for editing, but large-scale reindents can get pretty slow. And so on.)
We need tools that focus on application development needs, not text editing.