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

Reset terminal cursor style after each prompt #73

Merged

Conversation

caleb-allen
Copy link
Owner

@caleb-allen caleb-allen commented Jul 5, 2023

This is a fix for #72 and #51. The solution here is to print VTE_CURSOR_STYLE_TERMINAL_DEFAULT, whose value is "\033[0 q", to stdout after each prompt. When entering a new prompt line, this means that a reset sequence is sent, shortly followed by an IBEAM sequence. I had concerns that this would cause unpleasant flashing, but it seems to be fast enough that a block isn't rendered for quick commands. It works well in my testing with xterm, termite, alacritty, and the embedded terminal in vs-code (xtermjs I think?).

This does have an odd side-effect that the cursor returns to the default style while a long command is running, for example sleep(5).

In the course of testing this, I discovered that the vs-code terminal does not properly handle the control sequence for resetting the cursor to the default style (\033[0 q). Instead, it sets it to a blinking block cursor. There is a well-detailed issue documenting this: xtermjs/xterm.js#3293

This might justify a new issue for this package. It's certainly annoying—we may be able to have a hacky mitigation detecting if any vs-code related libraries, and setting the cursor to block. Not a great solution though.

@caleb-allen
Copy link
Owner Author

caleb-allen commented Jul 5, 2023

I've made some changes. Now, instead of being called after every prompt, it's called by using registering a callback with atexit .

Also, using the cursor reset sequence yielded inconsistent results across terminals. I was confused, because when using vim it seems that the cursor is correctly reset regardless of the shell or terminal.

It turns out that when vim exits it just sets the cursor to whatever its normal mode setting is! https://github.com/vim/vim/blob/d392a74c5a8af8271a33a20d37ae1a8ea422cb4b/runtime/doc/term.txt#L737-L738

If it's good enough for vim then it's good enough for us! Thus, these changes set the cursor to "steady block" on exit.

@caleb-allen caleb-allen merged commit 77e4538 into master Jul 5, 2023
@caleb-allen caleb-allen deleted the caleb-allen/return-cursor-to-normal-mode-upon-exiting branch July 5, 2023 16:23
caleb-allen added a commit that referenced this pull request Jul 14, 2023
Set the terminal cursor to block style when the REPL exits by using registering a callback with `atexit` . Fixes #72  and fixes #51. 

Also, using the cursor reset sequence yielded inconsistent results across terminals. I was confused, because when using vim it seems that the cursor is correctly reset regardless of the shell or terminal. 

It turns out that when vim exits it just sets the cursor to whatever its normal mode setting is! https://github.com/vim/vim/blob/d392a74c5a8af8271a33a20d37ae1a8ea422cb4b/runtime/doc/term.txt#L737-L738

If it's good enough for vim then it's good enough for us! Thus, these changes set the cursor to "steady block" on exit.
caleb-allen added a commit that referenced this pull request Jul 20, 2023
Set the terminal cursor to block style when the REPL exits by using registering a callback with `atexit` . Fixes #72  and fixes #51. 

Also, using the cursor reset sequence yielded inconsistent results across terminals. I was confused, because when using vim it seems that the cursor is correctly reset regardless of the shell or terminal. 

It turns out that when vim exits it just sets the cursor to whatever its normal mode setting is! https://github.com/vim/vim/blob/d392a74c5a8af8271a33a20d37ae1a8ea422cb4b/runtime/doc/term.txt#L737-L738

If it's good enough for vim then it's good enough for us! Thus, these changes set the cursor to "steady block" on exit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant