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

WT stops cursor blinking after quitting Emacs nox build #12372

Closed
angelog0 opened this issue Feb 4, 2022 · 8 comments
Closed

WT stops cursor blinking after quitting Emacs nox build #12372

angelog0 opened this issue Feb 4, 2022 · 8 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@angelog0
Copy link

angelog0 commented Feb 4, 2022

Windows Terminal version

1.11.3471.0

Windows build number

10.0.19044.1503

Other Software

emacs nox build from master in WSL2
emacs msys2 package (for terminals)

Steps to reproduce

  • Start WT-WSL2: cursor is blinking
  • Start Emacs: cursor is blinking
  • Quit Emas: at WSL prompt the cursor is no longer blinking.

The same occurs running, in WT, Emacs from MSYS2 package.

NOTICE that THE SAME STEPS in MinTTY terminal (with or without WSL) produce a BLINKING cursor after quitting Emacs!.

I see there are similar issue flagged here but in my case the cursor stops blinking ONLY after QUITTING Emacs, not running a curser app...

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 4, 2022
@j4james
Copy link
Collaborator

j4james commented Feb 6, 2022

I'm almost sure this is the same thing as #10754, and Emacs is probably using cnorm/cursor_normal on exit, which disables the cursor blinking mode.

I'm not sure why you're getting different results in Mintty, unless you've configured your TERM variable to something weird. If you execute tput cnorm in Mintty, does that disable blinking?

@angelog0
Copy link
Author

angelog0 commented Feb 8, 2022

@j4james, I did not change TERM in MinTTY. It still is

$ echo $TERM
xterm

BTW, after I quit Emacs (and cursor stops blinking), restarting Emacs the cursor returns to blinking in Emacs; exiting one more time, it returns to stop blinking...

@j4james
Copy link
Collaborator

j4james commented Feb 8, 2022

I think I know what's happening now. It looks like Mintty ignores the blinking escape sequence (private mode 12) if you've set your default cursor preference to be blinking, so that's why it appears to be working. Emacs is still requesting that the cursor stop blinking, but Mintty is simply ignoring that request.

BTW, after I quit Emacs (and cursor stops blinking), restarting Emacs the cursor returns to blinking in Emacs; exiting one more time, it returns to stop blinking...

That is exactly what I would expect. They're likely using the cvvis terminfo capability on startup (which enables cursor blinking), and the cnorm capability on shutdown (which disables blinking).

The bottom line is that this is a duplicate of #10754 and is really an Emacs problem. You can probably work around it by editing your terminfo if you don't ever want applications to stop your cursor blinking.

@angelog0
Copy link
Author

angelog0 commented Feb 9, 2022

If you execute tput cnorm in Mintty, does that disable blinking?

No...

@Eli-Zaretskii
Copy link

Is there a way of detecting whether the terminal cursor blinks? If so, Emacs could do that at startup.

@j4james
Copy link
Collaborator

j4james commented Feb 10, 2022

@Eli-Zaretskii There is an escape sequence which several terminals support that can be used to reset the cursor to the user's preference - both the shape and blinking. To see how that works, type printf "\e[ q" from a WSL shell.

Emacs is unlikely to use that, though, because I suspect they do everything through ncurses, but if they have the concept of shutdown script, you could maybe configure it to output that sequence yourself. That's what many vim users do.

@zadjii-msft
Copy link
Member

Thanks for the investigation @j4james!

/dup #10754

@ghost
Copy link

ghost commented Feb 23, 2022

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

4 participants