[hnlmorg]

You can change it though. Several people in this conversation have suggested ways to make that change.

What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem.

Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago).

I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep:

    (void) napms(1000);

If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet?

If feels to me like there a real lack of objectivity in this thread.

[IshKebab]

> If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet?

Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow.

And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.

[hnlmorg]

If I'm obviously wrong then I assume you can point me to an independent study that proves a 1 second delay in `reset` has measurable significant impact on peoples productivity?

[IshKebab]

> If I'm obviously wrong then I assume you can point me to an independent study that proves a 1 second delay in `reset` has measurable significant impact on peoples productivity?

That's the wrong question. Nobody has done that study because it's obviously bad to have 1 second delays that aren't needed!

Show me an independent study that proves a 1 second delay has no negative impact on productivity or satisfaction.

[hnlmorg]

You're the one making a claim. Not me

But I can see nothing further is going to be gained from this conversation so I'll end it here

[phone[phone]]

How often is your terminal getting scrambled to the point where you're running 'reset'?

I have to run it, tops, maybe once a day when a remote screen session gets disconnected.

[IshKebab]

Very often unfortunately. But even when it doesn't I use `reset` to clear the scrollback history so it's easier to get to the start of a command.

I'd really like terminal emulators to support marking the default top of the scrollback so I don't lose the earlier history but still get the benefit of being able to easily find the start of a command, but I'm not aware of any terminal emulators having any features that do anything like that. So `reset` is the next best thing.

[hnlmorg]

Lots of terminal emulators support graphical hints to box command output together. There was even a discussion about this exact feature just a few days ago on HN.

You can also emulate this behaviour in your shell using the prompt string. Which is something I see a lot of people do too.

You probably can’t do either of these things in the VSCode term that you like, but that term is shit.