[jiggawatts]

One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not.

What are they talking about!?

I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over double buffering.

Practically every editor I use updates with the maximum 60Hz refresh of my monitor, and that literally can't be improved upon any further through software alone. The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor, not a simple fixed-width text editor.

I mean, seriously: I'm playing Doom Eternal at 4K with a constant 60fps, no dips. That game is processing a decent chunk of a terabyte per second of data at that rate.

What is this mysterious difficulty people have with editing ~100KB text files!?

Either this forum is full of people editing insane multi-gigabyte files (By hand? Why!?) or they're doing it on their 486SX PCs for nostalgia reasons.

I seriously don't get it.

[crazygringo]

I dunno why you haven't encountered it, but it's a real thing.

I remember using one editor perhaps 8 years ago, and if I tried multi-cursor mode with more than ~40 insertion points (totally reasonable to edit 40 similar lines at a time), it took a couple of seconds to register each keypress.

Similarly, other editors wind up choking on syntax highlighting, or large files, or find & replace, or documentation lookup, or whatever.

The "mysterious difficulty" you mention is often literally several seconds of latency with, say, a 30,000-line file, whether it's with opening, scrolling, editing, or the other more advanced features already mentioned.

I'm honestly pretty baffled this isn't something you've encountered before. This isn't about hertz, it's literally about entire seconds or large fractions thereof.

[jiggawatts]

I regularly use Notepad, Notepad++, TextPad, VS Code, Visual Studio, and the PowerShell ISE. I haven't had any issues with any of them, even when block-selecting or multi-cursor editing.

Notably, they're all Windows native apps written in C++, with the exception of VS Code, which is partially JavaScript.

I've noticed that some of them struggle with huge (1 GB) files, but editing such as large file is a somewhat strange thing to do.

[crazygringo]

I mean, that's great for you. You're just lucky I guess.

But I hope what I described makes sense to you. It's not about 1 GB files at all, it's about regular files. My suspicion is that it's mostly "side features" that start to grind when they get beyond a certain point.

To be more specific with one example, I've used another code editor that a simple "find all" operation will populate a results box. If you mess up your regex to be accidentally super-generic and it finds 100,000 results in your 20K-line file, it takes half a minute to load the results into the results box and become responsive again, with no "cancel" button.

Similarly weird edge cases in a syntax highlighter interacting with a half-finished line of code of yours causes something to choke up. That kind of thing.

Do you understand now? Again, you seem to just be lucky that you haven't encountered this kind of thing.

[osdiab]

I develop on a 2018 dual core 16GB RAM MacBook Air, which is a lot crappier spec-wise than your gaming rig (but not crappy enough that text editing ought to be a problem). Often typing in VSCode on a large TypeScript project can take hundreds of milliseconds to register my keystrokes, which may have to do with the machine being overloaded by too many Electron apps (switching from Chrome to Firefox as my main browser already feels better), or maybe it’s that the Typescript language daemon or an errant extension is doing too much work - whatever it is, I haven’t figured it out, and dropping in some replacement text editor that claims to be fast might be a quicker way to get my dev setup more tolerable than my current experience.

I recently got Neovim working with nvim-typescript but I would be lying if I didn’t say I missed the nice UI/UX of VSCode, nor that I’m annoyed at having to spend so much time configuring my editor and memorizing shortcuts instead of actually getting things done.

So to answer your question I think part of it is that my machine is just worse than yours, and part of it is that editing text is often doing more than just editing text - in my case keystrokes trigger static analysis of a large project.

[geitir]

Did you try sublime? Also try running bootcamp because my personal conspiracy theory is Apple only optimizes their releases for the latest hardware

[JSavageOne]

The difference in "snappiness" between Sublime Text and VS Code is extremely noticeable. The startup time in particular is substantially slower on VS Code (not just on the initial startup but also upon loading new windows)

The reason I still use VS Code is because the additional features for coding make it worth the unfortunate performance cost, but whenever I'm just working with basic markdown files I always go to something like Sublime.

[CuriousSkeptic]

When I was running Linux one metric that mattered to me in choice of editor was the time it took to launch an editor from command line.

Anything spending time loading plugins or whatever before giving you text on screen and responding to commands is frustrating if the only requirement is to quickly tweak a setting in a config file or just viewing a text file.

I guess it’s less noticeable on windows since everything is GUI based and quite unresponsive by default. But when spending your days in a terminal you get used to a certain snappiness that’s noticeable once interrupted.

Edit: Btw an interesting in-depth analysis of typing latency with measurements https://pavelfatin.com/typing-with-pleasure/

[tomcooks]

While the reason could easily be that not everyone has the horsepower you're used to (I assume 60FPS at 4K requires a certain level of hardware), people often mean something other than high speed when they say "snappy": ease of use, good descriptive UI that gives you feedback on actions and their results, certain features that simplify tasks such as integration with other tools (git compilers, etc.).

Also add other factors such as remote editing, say on a VPS with 512mb RAM with too many daemons running.

[jiggawatts]

> remote editing, say on a VPS with 512mb RAM with too many daemons running.

I really like the new VS Code remote-editing feature, where the GUI is local but you can work directly on the remote system.

Visual Studio has a vaguely similar "remote debugger" feature.

Generally I avoid remote development like the plague. As you said, the latency is quite noticeable through any kind of remote connection.

Pro tip for anyone using Windows: Modern versions limit RDP to 30Hz by default, irrespective of CPU power or available bandwidth. See this MS article on how to remove the limitation: https://support.microsoft.com/en-au/help/2885213/frame-rate-...

I always set this to 60 Hz on high-performance "workstation" VDI systems used by developers.

[jussij]

I don't think screen frame rate is a good measure when it comes to measuring editor responsiveness.

For me the only time screen response comes in to consideration is for flicker.

Editors that flicker badly can be very annoying and very distracting.

My measure of editor responsiveness would be a count based measure of the numbers times you can find yourself waiting on the editor.

Now this waiting can happen for very many different editor actions, but it is most annoying for anything that is keyboard input related.

Snappy editors have very few of these wait points, whereas slow editors drive you mad as you find yourself constantly waiting for some action to complete.

[bArray]

> What are they talking about!?

You're missing the point with refresh rate, you could make the slowest implementation in the Universe have a snappy UI thread.

> What is this mysterious difficulty people have with editing

> ~100KB text files!?

Most editors will open the entire file into RAM, which is not such a problem unless is starts trying to index everything for searching, colourizing everything, etc, etc. What feels like a great feature for ~10kB source files starts to chomp away at CPU and RAM for some file >1MB as your editor tries to find patterns in some binary file.

> I mean, seriously: I'm playing Doom Eternal at 4K with a

> constant 60fps, no dips. That game is processing a decent

> chunk of a terabyte per second of data at that rate.

That's quite the powerful machine you have. Consider many people will operate with laptops and some of them are low-power, high battery life. Also consider that many will not just be doing that one thing. I know quite a few people now doing serious dev work from tablets... (They use build servers.)

Also, just because you do have the latest processor available doesn't mean that I expect a simple text editor to consume everything it has.

[leeoniya]

you may find this interesting:

"Why are 2D vector graphics so much harder than 3D?"

https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...

[jiggawatts]

I think I've read that article already! Computer graphics has always been an interest of mine, and I've written 3D engines before.

Admittedly, not a 2D text engine, but I keep up with the research.

The difference between the blog post you linked and a programmer's text editor is night & day.

There's a huge difference between arbitrary 2D graphics and fixed-width text rendering. The former has crazy complex corner-cases, and also has to deal with all of the fun things 3D engines do such as arbitrary transformations and transparency.

A web browser has to deal with the arbitrary case, which is why Firefox's new Rust-based renderer took so many years of hard work to write. It's a complex beast.

A fixed-width text editor is more or less just putting sprites on a grid. Sure, there's subpixel alignment, antialiasing, and maybe even ligatures, but this is nothing really in comparison. They're all "local" issues where typically at most a few hundred pixels are affected per character update.

Or to put it another way, text editor rendering is "embarrassingly parallel". The screen can be split up into lines or char blocks and each can be drawn separately and updated individually when modified.

Compare this to 3D games that are pumping out 4K pixels every frame, updating all of them every time. Web browsers do the same thing, they have to update the entire screen every frame in a lot of scenarios and can manage this at 60 Hz too. Firefox and Chrome both can do this now for much more complex scenarios than text editing.

[z3t4]

We are very sensitive when it comes to text. 3d games doesn't need to be accurate, compared to text that needs sub pixel perfection. 3d is closer to the metal and thus faster. Ive made a web based text editor that parse the entire file on each key press to get language intellisense and semantic coloring, that however only takes 1ms. Rendering one full screen of text takes around 10ms. That's how slow text rendering is. Taking into account random GC pauses and graphics layering overhead there's little budget left for parenthesis matching highlighting, auto completion suggestions, auto quote insertion, spellchecking, etc.

[maximilianburke]

I use vim as my primary editor. I've tried a number of times to pick up VSCode. The functionality is there. The modal keybindings are there. But yet it lags and I can deal with it in the short term but over the course of a day my frustration mounts and I end up going back.

There's a difference as well between refresh/frame rate and input lag. It is very much possible for a game to have a consistent 60hz frame rate but yet lag. Lag can come from delays in the input subststem, it can come from buffering before display, it can come from the display itself.

Here's a good read: https://www.eurogamer.net/articles/digitalfoundry-2017-conso...

[zwaps]

The suspicion may also be induced by other software.

Ever tried early RStudio (or even current) on a crappy work-issued laptop? And I don't mean R, I mean the UI elements.

This is a great piece of software, certainly more than a text editor. But it isn't as fast and snappy as a native editor, far from it. It's tolerable now, but it used to be pretty bad on non beefy hardware.

At the same time, native IDEs did not have that issue at all.

[matthewhartmans]

This is a thing man.

I'm running a Pentium powered notebook and VS Code runs like a dog.

Another factor to consider is you might be running other things in parallel to editing your files (terminal watching and compiling code, a web browser for viewing output, etc).

[tsukurimashou]

try pretty much any electron app, try a web browser on mobile (these days even a simple google search sometimes freezes my phone for a few seconds with the message "unresponsive script") if you can't feel it maybe you got used to it, but try some CLI program and you'll see the difference.

[kinkrtyavimoodh]

> The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor

Was the shitty there qualifying WYSIWYG (as in WYSIWYG editors are definitionally shitty) or qualifying MS Word (as in MS Word is a shitty editor)?

If the latter, do you have suggestions for good WYSIWYG editors?

[jiggawatts]

MS Word has... many problems, but being WYSIWYG is not one them. I like WYSIWYG editors.

I write a lot of reports these days, and the Word editor interface drives me crazy. Like I said, it's slow, irrespective of the hardware. It can't even maintain a consistent 30 Hz on a high-end gaming rig when editing plain-text paragraphs with no special formatting. I suspect it's throttled internally, but it could just be badly written.

The editor is also very glitchy in the way it handles formatting. Lots of little annoyances just haven't been fixed and have been left there to fester for decades. It's all too easy to corrupt a document's styles to the point that the only reasonable fix is to carefully cut & paste all content into a new document, going through Notepad on the way to guarantee all hints of the original formatting are stripped.