[mafuyu]

It’s the small latencies that add up for me. I usually use a tmux + nvim setup, but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust), I have a VS Code setup with the nvim plugin that I’ve spent way too many hours tweaking hot keys and things.

Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition between panes and such. Even just scrolling with nvim keybinds feels a bit off. My key repeat rate is fairly high, and I’ll hold down ^D to skim through a source file. VSCode’s renderer struggles to keep up smoothly sometimes.

This is all nitpicky stuff, not enough for me to swear off VSCode or anything. But it’s just annoying enough that every once in a while I end up in some rabbit hole of VSCode internals and css tweaks, instead of doing actual work. Most coding does not require a ton of bouncing around, but it does feel very liberating to have confidence in my inputs as I navigate around.

[dleink]

Wow, that's a great way to phrase it. I'm currently setting up a basic laptop with speed like you're describing as a goal. "Confidence in my inputs" is an underrated value in HCI. Of course websites have to implore users to not click on this again while it loads, they don't have confidence in their inputs!

[saurik]

Something actively dropping inputs is an entirely different category of problem than it merely being slow to process them.

[dleink]

Yes, But for "confidence in inputs" the difference doesn't matter.

[saurik]

I honestly don't see that? If it drops inputs, you can't have confidence in your input; but, if it is merely slow to process them, then you don't lose confidence. If you know for sure that something will happen--and even that it will happen in the correct order, as in this case--you can just move on with your life. Have you never worked with a remote text editor over high latency? Or played a musical instrument that had a slow reaction time?

For avoidance of any doubt, I care deeply about my editor latency and agree that those terminals who claim to be "fast" and yet only care about average--not even common--throughout instead of latency misunderstand the problem space... and yet, I still can't say that it is reasonable to lose "confidence in your inputs" if a system is merely slow to process without losing any of your events. If an editor drops any of my inputs at all ever I 100% lose all confidence in what I'm doing; but if it always works then I can close my eyes and still use it without issue!

[mafuyu]

I think this gets at my feelings on latency as well.

Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)

With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.

With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.

(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)

[bemusedthrow75]

You are a data point for the notion I mention in my own reply to the parent that keyboard-only navigators might be feeling this more than mouse/trackpad users. Which seems likely to me.

[mafuyu]

Agreed. I elaborated a bit more in a sibling comment about how many keybinds result in opening a pane and focusing it, and it’s just not built for being operated by keyboard. Although you could make the argument that using the mouse just hides all the latency. Scrolling through text buffers is super smooth… but at what cost?

[WuxiFingerHold]

> but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust)

Unfortunately, for this use-case, neither Zed or Laplace will likely to fill the gap, as they rely only on LSP as Neovim. That's also my issue with both: They should focus more on providing features to support coding, not just speed.