[diceduckmonk]

> designed for modern hardware with a focus on responsiveness and performance

Not sure why a text editor needs modern hardware to be performant. I’m working on a text editor myself, and aspire to vim on the performance front as it is fast as one would reasonably want. If anything, my physical body is the bottleneck. There are edge cases such as really large files (100+ million lines) or ones having super long lines that makes certain data structures choke, but vim can do random access on 180m line files just fine on my M1.

Point being, performance is a weak selling point to switch text editors, and I question whether it should even be predicated on “modern” hardware ( GPU accelerated rendering ? ). The selling point has to be something else. This is why the editor wars is a dichotomy between Emacs and Vim. Emacs strives for many things, but speed isn’t one of them, and that’s perfectly okay. The main selling point of my editor, built for myself, is native support for Org-like files without the rabbithole of Emacs.

[imiric]

Performance in text editors used for programming is important. If there's a delay between pressing a key and something happening, it's a worthwhile goal optimizing for that. Consider how many things can happen in modern editors with a single key stroke: changing large blocks of text, executing a macro, rendering syntax highlighting, communicating with an LSP server, rendering code completion, executing plugins, etc. All those things should happen in as few milliseconds as possible for the experience to be considered "responsive".

I use Emacs on a daily basis, and even with the recent native compilation change and relatively few packages, some common actions feel noticeably slower than in Vim or other editors. Is this a dealbreaker? No, I made a conscious decision to get the flexibility of Emacs at the expense of performance, but I would jump at the opportunity to use something with the same featureset that _does_ prioritize performance. It's not about how productive it would make me, but how enjoyable the experience of using it would be.

[Semaphor]

Most people use neither Emacs, nor Vim [citation needed, but I’d bet some money on it]. And for me, performance is most certainly a selling point.

The main reason I use my windows text editor (EmEditor [0]) despite having no formatting and only barebones syntax highlighting, is that it’s faster than any other editor I’ve ever seen (though I think the large file handler tops out at 256 GB). Well, that and its superior CSV handling, though Notepad++ comes close with plugins ;)

[0]: https://www.emeditor.com/

[anticodon]

I've seen voting results on one of niche Linux sites, and was surprised that majority of users use vim/neovim or vim bindings in other editors/IDEs.

But I'm pretty sure that most Windows users wouldn't use any editor resembling vim.

[dividedbyzero]

Visiting niche Linux sites often enough to take part in such a poll is probably introducing a very strong selection bias here.

[Aeolun]

> Point being, performance is a weak selling point to switch text editors

You’ve never worked with IntelliJ I see. If someone builds the exact same thing but any amount faster I’ll switch in a heartbeat.

I’m using Zed more and more, even though it has barely any of the features I use, purely because it’s so fast.

[z3t4]

Text rendering is very expensive. That's why you need hardware acceleration.

[kwhitefoot]

It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's. I wrote considerable amounts of code on the Z80 Apple II add on in the early '80s and never felt that the editor was too slow. My wife wrote a novel on our Osborne 1 (CP/M, Z80, 5 1.4 inch floppies) in Wordstar. Speed was never a problem for editing.

[naasking]

> It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's.

Sure, on machines with low resolution screens with simple fonts and no anti-aliasing. I'm not saying accelerated graphics are necessary for text editors today, just that the context has changed considerably so the comparison isn't obviously fair.

[CyberDildonics]

Are you really trying to say that 100 times the pixels (and a lot less in a window that isn't full screen) cancels out 10,000-20,000 times the CPU power (per core)?

[naasking]

CPU speed isn't the limit, memory speed is. Apple II's 1MHz to DDR4's 1600MHz is 1600x increase, so more modest than CPU gains.

Apple II's display was 280x192 with 6 colours in high res mode, which is ~107kB of raw pixel data (Apple II didn't store this all in RAM). An RGBa display at 1080p is least 105MB of raw pixel data. That accounts for the 1000x difference right there. Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.

Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:

https://danluu.com/input-lag/

[CyberDildonics]

You are conflating a lot of different things here and some of your math is off.

First, 1920x1080 pixels times 3 bytes for RGB is about 6.2 MB. I'm not sure where you got an alpha channel from. Also an entire screen of pixels isn't being copied from memory to refresh a text buffer.

Second the Z80 couldn't transfer a byte every cycle so that's 500KB/s.

Third, DDR4 doesn't have a bandwidth of 1.6 GB/s, which would be absurd. We can call that about 20 GB/s - https://www.transcend-info.com/Support/FAQ-292

The comparison for memory pixel data is 6.2 million / 107,000, which is 58. The comparison for memory bandwidth is 500KB to 20 GB/s, which would be 40,000.

Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.

These don't have anything to do with memory bandwidth and are back to CPUs.

Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:

This doesn't have anything to do with anything in this thread. The original person said text rendering was expensive, that has nothing to do with input latency.

[Aeolun]

Bitmap rendering is incredibly fast. Old computers were so slow it was the only viable method.

[kwhitefoot]

So new computers are slow because it is no longer the only method? Do they spend a lot of time on each frame dithering over how to do it?

[CyberDildonics]

If it's so expensive, why were computers a 10,000 times less powerful able to do it well?

[z3t4]

They only supported the ASCII characters and a few sizes/colors that was pre-rendered.

[CyberDildonics]

My 486 was able to do arbitrary text rendering without any problem. Text rendering is not expensive by any standard today. The only reason any text editor is slow is exceptionally poor programming or bad multi-threading (which is a little more forgivable).

[gigatexal]

Yeah -- while not mainstream compared to VSCode -- it'll take something very big and impactful to move me away from neovim + alacritty. It works amazingly well.

[noloblo]

What is neovim + alacritty

[bloopernova]

neovim is a fork of vim. https://neovim.io/

alacritty is a terminal application. https://github.com/alacritty/alacritty

[gigatexal]

What blooper said.

I use alacritty as a gpu-accelerated terminal and neovim plus the LSP stuff from VSCode

[gazsp]

I'm on Kitty + Lunarvim. Nice and fast / responsive.