So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable?
> Yes obviously it can be worked around by tens of thousands of people. We weren't discussing that. This is about the default which is clearly an insane default in 2024.
But what you're advocating isn't changing the default, it's changing the purpose of reset.
If people want something to clear the scrollback buffer then a new standard, and thus tool too, should be implemented. And in fact there are other ways to clear the scrollback buffer. You're just insistent on complaining that one very specific tool which is intended for a whole other purpose also clears the scrollback buffer slightly quicker...
> Rubbish. There are obviously other options:
> * Don't upgrade their software (almost certainly the case already).
That might not be an option. Some financial systems still use older style null terminals in places.
> * Install a version of `reset` that has the delay.
Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
> * Add an option to `reset` to add the delay.
That's not really practical on most systems because `reset` is just a symlink to `tset`
> * Stop using a physical terminal.
That's about as unhelpful a suggestion as it comes.
> If you're ever wondering why it will never be the year of Linux on the desktop, it's because of attitudes like yours.
Please don't make personal attacks. Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
If you bothered to do even the smallest amount of research on me, you'd realise that I'm massively in favour of modernising the command line. I've written a next generation shell that, frankly, leaves most others in the dust. And I'm not working on a terminal emulator that can in-line multimedia and other interactive GUI components. The problem here isn't my attitude, it's that the arguments in favour of changing `reset` are bullshit nonsense that both misunderstand the purpose of `reset` and also risk breaking a whole plethora of hardware because of that misunderstanding of yours.
>That might not be an option. Some financial systems still use older style null terminals in places.
But how many of those setups require a custom TERM and are unable to install a different package for reset.
>Given you're strongly against having to install a version of `reset` that doesn't have the delay, you're hardly in a position to demand other people to install a version that does.
The amount of people who need that delay is miniscule compared to the people who don't. Normal users don't need the delay, only exotic setups, which is why the default does not make sense.
>That's not really practical on most systems because `reset` is just a symlink to `tset`
Then stop doing that.
>That's about as unhelpful a suggestion as it comes.
Not really. It has practical benefits and avoids down time of having to get it repaired or replaced.
>Plus waiting a couple of seconds for a command line terminal to clear when using one specific command has absolutely naff all to do with "the year of desktop Linux".
His comment was about your attitude of tailoring the system to a niche group instead of tailoring it to the billions of potential desktop users out there.
Let me be clear, I’m not against support your requirements. I’m saying ‘reset’ is the wrong tool to do that.
It’s like complaining that a text editor has no support exporting files as a PNG just because a subset of people happen to use that text editor for ASCII art.
If you want better support for clearing scrollback then that problem lies with ‘clear’, not ‘reset’.
Just as terminal capabilities lie with ANSI escape codes, not the TERM string.
The issue here is the pair of you are asking for the wrong thing then ignoring literally everyone else on HN and proceeding to make up insanely stupid claims about affected users (“billions of desktop users” lol) and call everyone else out for being unsupportive. Perhaps if you bothered to listen to people you might actually learn something.
Windows has also maintained backwards compatibility to a ridiculous extent, and there have been a bunch of "year of the Windows desktop", so I don't think it is detrimental that Linux does the same.
The issue is not about maintaining reasonable backwards compatibility. It's about refusing to fix things and using ridiculous backwards compatibility as an excuse.
1. Even Windows doesn't maintain full backwards compatibility all the way to the 90s, which is what you are advocating.
2. You could even fix this in a backwards compatible way if you wanted!
Also I never said anything about "full backwards compatibility". I just think this specific compatibility is worth preserving because your justifications are weak (by your own admission, you're only arguing about it because you enjoy arguing with people on the internet).
> 2. You could even fix this in a backwards compatible way if you wanted!
It has been. You objected to those backwards compatible fixes.
I've also suggested a way of patching `reset` without relying on buggy usages of `$TERM`. That also apparently isn't good enough for you.
> you're only arguing about it because you enjoy arguing with people on the internet
Not at all. Firstly I clearly stated a second reason so that isn't the only reason. And secondly, that's orthogonal to whether or not I'm right. If I didn't enjoy debating I wouldn't bother but I would still know that maintaining this delay is idiotic.
> It has been. You objected to those backwards compatible fixes.
It has not. If I install a default Linux distro, the default configuration is to insert stupid delays everywhere.
I have to go out of my way to remove them. That. Is. Dumb.
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.
> 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.
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?
> 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.
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.
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.
Ridiculous