I love the "It's harmless with a terminal emulator". I (obviously) get what they're saying, but you'd think making millions of people waste 3 seconds of their lives every time would be considered at least a modicum of harm.
reset wouldn’t be used used by millions of people and most of those who do use wouldn’t be using it regularly either.
reset should be a last resort. If you need to use it then something else has gone wrong and thats what needs to be fixed.
I’m all for modernising our terminal but in this instance we are talking about a last resort command taking 3 seconds longer than needed just in case some of some edge case scenario occurs. So 3 seconds is definitely not harmful.
> making millions of people waste 3 seconds
> That's a touch exaggerative don't you think?
Literally!
A terminal emulator is the software application you use to bring the command prompt up. So a terminal emulator is operating system agnostic.
Granted there are some macOS only terms out there like iTerm2 and Apples own Terminal. Just as there are terminals that haven't (as far as I'm aware) been ported to macOS, like xterm. But there's plenty of cross platform terminal emulators too, in fact most are cross platform.
Sadly Kitty is very bare-bones. Not really for me. And I can't choose to use Kitty in VSCode.
I said most terminal emulators are cross platform and that hot key isn't an OS dependant thing. You then reply with:
> On Mac you can press Ctrl-K in any terminal emulator ... > On Linux no terminal emulators support this
which not only contradicts what I said, it also misunderstands how terminal emulators work
> and I can't choose to use Kitty in VSCode.
So the issue is VSCode doesn't support ctrl+k? that's very different to the statement you opened with
Care to elaborate? I had an impression that it's a pretty complete piece of software. I've been driving it daily for more than 1½ years, and I'm pretty happy with it.
I didn't even realize, I don't see a need for it anyway.
> Ctrl-F to find, did not exist
That's because Kitty has something much better:
> Sometimes you need to explore the scrollback buffer in more detail, maybe search for some text or refer to it side-by-side while typing in a follow-up command. kitty allows you to do this by pressing the ctrl+shift+h shortcut, which will open the scrollback buffer in your favorite pager program (which is less by default).
> There's no menu bar at all in fact.
Which is a big plus. Emacs has a menu bar (and a toolbar), and I obviously turn them off, because they take up screen real estate.
Ah yes, the logical shortcut for "find" (enormous face palm).
Why do so many open source devs find sane UX so hard? It's a bit weird.
(And yes I know it isn't exactly the same as "find" - it that is your instinctive response then you're misunderstanding how UX works.)
Gnome Terminal sensible uses Ctrl+Shift+F to get around this. Kitty... does not.
> Incidentally, using the term UX itself, generally is a good signal that the person that is using it doesnt have a clue what they are talking about.
Of course you think that.
And pretty much anyone that has to deal with internet commenters using the term UX thinks that, not just me.
Er, my comment was exaggerative? (edit: fixed typo)
I use reset all the time, it's not "last resort" by any means. It... clears the screen and scrollback buffer. If you're the kind of person who keeps 150 tabs open then I guess I can see why you wouldn't see the value in cleaning the screen up frequently, but clearing the terminal is a pretty frequent and useful operation for other folks.
You could try echo -ne '\ec' or echo -ne '\033c'. Or this from bash/readline:
clear-display (M-C-l)
Clear the screen and, if possible, the terminal's scrollback buffer, then redraw the current line, leaving the current line at the top of the screen.
reset() { clear && printf '\33c'; }[1] https://wezfurlong.org/wezterm/config/lua/keyassignment/Clea...
I actually do that a lot, when I'm done with a terminal window for now but want the scrollback to stay there. ctrl-L to send a pagebreak is what I usually do, or typing something aliased to `clear`.
Why wouldn't you use "clear" for that, or Ctrl+L? "reset" does a lot more, you use it when you've accidentally written a binary to your terminal and triggered a bunch of terminal modes.
I guess clear wouldn't clear the scroll buffer, is that the main reason?
Yes. See sibling replies.
On any non-libvte using terminal emulator, eg. xterm, you can use CTRL+L to clear the text area and ALT+CTRL+L to clear the text area and the scroll buffer.
No it wasn’t. But I also said exaggerative not aggressive.
> I use reset all the time, it's not "last resort" by any means. It clears the screen.
That’s what ‘clear’ is for.
Reset is intended to do more than just clear the screen. It’s intended to reset, as the name suggests, the entire terminal. The idea being it’s got itself into some kind of unknown state.
There are hot keys to clear your screen too, such as ctrl+L (works in most shells) plus your terminal emulator will likely have its own hot keys too. So fewer button presses and even quicker for you.
lmorg ~ % reset
lmorg ~ % reset
lmorg ~ % which reset
/usr/bin/reset
lmorg ~ %
function reset {
printf '\033c'
}
Because of this, there isn’t really any standardisation for how scrollback should work. Every terminal could implement it differently (albeit in practice there isn’t a whole lot of variation one can do to such a simple concept). So support for how you clear your scrollback is going to vary from one terminal emulator to another. As I demonstrated in an earlier comment with ‘reset’ not clearing the scrollback on one terminal in macOS.
Really there should be a dedicated ANSI escape code for doing this. There’s a few different codes for clearing the terminal already, one extra wouldn’t do any harm there. Plus xterm has already introduced the concept of bespoke codes for application terms like window title (something other terms have expanded on with codes to move the terminal window).
In fact, I’m going to create a code for just this and implement it in my own terminal emulator and others are welcome to adopt this as a new de facto standard if they wish.
Anyway, that’s the history of why you had such a hard time. None of this is intended to justify the status quo, and I do accept that this is all a bit frustrating to newcomers. But as I said before, I don’t agree the solution is to change the purpose of ‘reset’. Instead terminal emulators should be supporting new functionality to manage something that they added to the paradigm — and to be fair, most terminal emulators already do.
FWIW, the default Linux console had scrollback until a few years ago when it was removed in Linux 5.9.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Linus' comments on that commit are interesting to note too. Because, in my opinion, they add weight to the comments made on here regarding the annoying non-standardised complexities to terminal scrollback.
I think that is the real problem here.
What? This is not my idiosyncratic opinion. This is literally what cls ("CLear Screen") does on Windows.
By the way, did you know that up to and including some versions of MS Windows 10 "clear" in Powershell only cleared the screen, as did "cls" in cmd.com. Considering the name, that would actually be what I expect "cls" to do, but I digress. Since some later MS Windows 10 versions or the very least, MS Windows 11, Powershell and cmd.com do clear the screen and the scroll buffer on "clear" or "cls". That's due to newer versions of ConPTY.
Anyway, it was fun digging out this old knowledge. Thank you.
If your terminal emulator doesn’t even have that, I suggest switching to a better one.
I hope you realize you’re doing something really suboptimal here.
Edit: Saw your other comment and apparently you don’t even use reset(1), just your own function (which is still suboptimal like I said). WTF is with all the arguing then.
And it adds up: 100ms here, 200ms there, times millions of users, times dozens of times per day the issue happens, and it's no wonder our 2024-era supercomputers still feel about as slow as my 2004 Windows XP machine.