Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: ResetTerminal action #4199

Closed
mitar opened this issue Sep 1, 2020 · 6 comments
Closed

Feature: ResetTerminal action #4199

mitar opened this issue Sep 1, 2020 · 6 comments

Comments

@mitar
Copy link

mitar commented Sep 1, 2020

I think it would be useful to have a ResetTerminal action, so that I could tie it to a keyboard shortcut to reinitialize the terminal. This could be useful when I break it so much that typing reset it not viable, or if I am not inside a shell but some other program (although I am not sure if it would work there).

It is not something I use often in other terminal emulators, but sometimes I do and sometimes it fixes the issue (and sometimes I just restart the terminal emulator app).

@nixpulvis
Copy link
Contributor

nixpulvis commented Sep 2, 2020

I expect this will have the same issue as #4152.

Again, as @kchibisov has mentioned in the other thread, there's really nothing stopping you from finding the pts/<N> of the terminal that needs reset and sending it echo -e "\ec" > /dev/pts/<N>.

However, an easier way to get this functionality would still be nice in my eyes. I understand I'm arguing for something we've explictly stated we don't want, but given that the ability to push arbitrary escapes through /dev/pts exists, and terminal applications are not all going to be horribly broken by this, I feel that if anything would be allowed, perhaps it would be a reset action. The use case for this is clear, something gets messed up, and the user cannot currently send escapes any other way (killing a running program is not always an option).

Rather than implement this action as a one off, why not allow sending arbitrary escapes, this really would open up a number of user configs which aren't possible today. If a user configures their terminal to break their application, I see no problem TBH.

@chrisduerr
Copy link
Member

This is indeed the exact same thing as #4152 and #3997.

In general, people that know what this binding actually does and when it should be used, will have no problem doing the same thing without it. The only thing that could be brought up is making it simpler, but I really doubt you find yourself in a locked up terminal without being able to type reset that much. In general typing reset is available and I'm not aware of the last time it wasn't for me.

The use case for this is clear, something gets messed up, and the user cannot currently send escapes any other way (killing a running program is not always an option).

Do you have any examples of where "something gets messed up" with a running program the user cannot interrupt? I'd struggle even intentionally putting myself into that scenario.

Rather than implement this action as a one off, why not allow sending arbitrary escapes

That has already been discussed before and the arguments really haven't changed. I'm not aware of any way this could be used which wouldn't be abuse of the feature.

@kchibisov
Copy link
Member

I think it would be useful to have a ResetTerminal action, so that I could tie it to a keyboard shortcut to reinitialize the terminal. This could be useful when I break it so much that typing reset it not viable, or if I am not inside a shell but some other program (although I am not sure if it would work there).

What's the point of explicitly going dsync with a program, if the program reached a broken state ctrl + z, reset, fg. But I've never done that in my entire life, since it's something that doesn't happen often, it's also really hard to identify that something requires reset. I guess the whole purpose of such special action is 'connection lost' in ssh, so you may need reset, but you have access to shell, and if it's not, then you're running some other program and resetting will corrupt its state, meaning that you must restart it anyway.

I'm not sure why we're reiterating this issue, since you can bind reset yourself if you really want to. not sure why you need a dedicated binding for that.

@chrisduerr
Copy link
Member

Since there have been no arguments brought forward that would justify this, I'm going to close this issue for the same reason as #3997.

@space-pagan
Copy link

I doubt this will make much difference in your mind, but I spend a lot of time in gdb, and have been sorely missing the ability to clear my screen without leaving gdb for clarity of reading the output, which both gnome-terminal and Konsole were able to support via reset & clear before I switched to alacritty. I understand that this is, again, not the intended purpose of 'reset', but I also think it's strange that given the fact other people have already gone so far as to write the code for you, you still refuse to implement such a basic function.

@avindra
Copy link
Contributor

avindra commented Dec 4, 2020

I'll share once more the external workaround for resetting the terminal. cc @space-pagan

To be clear: this is the reset that erases everything, not just the scrollback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

6 participants