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

Add support for DECSCUSR "0" to restore cursor to user default #7379

Merged
15 commits merged into from
Sep 4, 2020

Conversation

skyline75489
Copy link
Collaborator

@skyline75489 skyline75489 commented Aug 24, 2020

This PR is about the behavior of DECSCUSR. This PR changes the meaning
of DECSCUSR 0 to restore the cursor style back to user default. This
differs from what VT spec says but it’s used in popular terminal
emulators like iTerm2 and VTE-based ones. See #1604.

Another change is that for parameter greater than 6, DECSCUSR should be
ignored, instead of restoring the cursor to legacy. This PR fixes it.
See #7382.

Fixes #1604.

@skyline75489
Copy link
Collaborator Author

I don't think this actually fixes #1604 as vim does not attempt to restore cursor shape on exit. So..what do you guys think?

@skyline75489
Copy link
Collaborator Author

Hey seems we got VS 16.7 for CI build now?

src/terminal/adapter/DispatchTypes.hpp Outdated Show resolved Hide resolved
src/cascadia/TerminalCore/TerminalApi.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/adaptDispatch.cpp Outdated Show resolved Hide resolved
src/terminal/parser/OutputStateMachineEngine.cpp Outdated Show resolved Hide resolved
src/terminal/parser/OutputStateMachineEngine.hpp Outdated Show resolved Hide resolved
@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 24, 2020
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 25, 2020
Copy link
Member

@miniksa miniksa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks @j4james for making the first pass and @skyline75489 for fixing those things up before we got back around to this.

Comment on lines 2163 to 2166
case DispatchTypes::CursorStyle::BlinkingBlock:
case DispatchTypes::CursorStyle::BlinkingBlockDefault:
fEnableBlinking = true;
actualType = CursorType::FullBox;
break;
Copy link
Collaborator

@j4james j4james Aug 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the behaviour for conhost is right. We should either leave UserDefault as an alias for BlinkingBlock, which is at least compatible with the DEC standard, or we should try and map it to the actual user preference (which I'm honestly not sure how to do). Worst case we could possibly map it to blinking legacy, which I think is the system default. But as it stands, it looks like you're going to get non-blinking legacy, which is neither one thing nor the other.

Edit: Sorry this is essentially a long-winded dup of DHowett's comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More detail = more good

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I really have anything to add that Dustin and James didn't already - We should probably add the plumbing for DispatchTypes::CursorStyle PrivateGetDefaultCursorShape() to getset, conGetSet, outputStream, etc, so that adaptDispatch can do the right thing for conhost, but everything else looks good here.

@zadjii-msft zadjii-msft added Area-VT Virtual Terminal sequence support Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal. labels Aug 25, 2020
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually you know what, I'll block over that

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 25, 2020
@skyline75489
Copy link
Collaborator Author

skyline75489 commented Aug 25, 2020

This may be irrelavant but when I'm using stock cmd.exe and then wsl.exe, the cursor will restore to default after vim exits. I don't fully get it why..

Update: it actually restores the cursor style to default, not just vintage. If I change my preference in the propsheet Dustin mentioned, it will restore to that style accordingly.

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 25, 2020
@DHowett
Copy link
Member

DHowett commented Aug 26, 2020

the cursor will restore to default after vim exits

vim was written for versions of windows that did not support VT, and therefore it almost exclusively uses the traditional console APIs. This includes a custom reimplementation of alternate buffers and manual cursor management.

@skyline75489
Copy link
Collaborator Author

@DHowett But I'm using vim in WSL, right? So it's a Linux Vim, not win32 vim.

@DHowett
Copy link
Member

DHowett commented Aug 26, 2020

using WSL vim

oh, right. whoops. :)

I do not believe that it restores the cursor state by default. i will continue to be unable to apply reading comprehension :)

@zadjii-msft
Copy link
Member

I'm gonna hold off on merging this for a bit to give @j4james a chance to voice any objections, since he's still on "requested changes".

Comment on lines 420 to 421
default:
finalCursorType = CursorType::Legacy;
shouldBlink = false;
return true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: If we're now treating unrecognised parameters as a no-op in Windows Terminal (which is good), should we not be doing the same thing for conhost in AdaptDispatch?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t know how can we debug conhost now. So I intended to keep this. By the way do we want to fix this kind of small bug in conhost, or do we want to keep its behavior. I mean conhost itself is the legacy thing that shouldn’t be changed much for compatibility

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of the VT code in conhost is legacy, and this area of the code base is changing all the time. But we can always fix it in a follow-up PR if you don't want to do it now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I’m a little uncomfortable that I cannot unittest or manually test conhost. So I don’t feel right about changing that.

I think there’s no need to rush this. And Dustin is not available the next several days. I’m OK waiting for more voices and comments

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look in the Conhost folder of the of the OpenConsole solution, there's a Host.EXE project that you can run to debug conhost. In the Debugging section of the properties, the Command Arguments specify what shell to use - cmd.exe, bash.exe, etc.

As for the conhost unit testing, it'll depend on what exactly you're doing, but often that will be handled in ScreenBufferTests.cpp and/or adapterTest.cpp.

Copy link
Collaborator

@j4james j4james left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay. I only have one nit, and it's not a big deal, so I'm happy to approve this.

bool ConhostInternalGetSet::GetUserDefaultCursorStyle(CursorType& style)
{
const auto& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
style = gci.GetCursorType();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we’re on older Windows 10 or Windows 7, will this still work? I assume it will always return legacy.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the VT support was only added to conhost in build 10586 of Windows 10, so nothing prior to that should have any of this code. Maybe one of the core devs can confirm this, but I don't think we need to worry about older versions of Windows at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is totally fine. Conhost is also shipped as a totally independent unit -- so if conhost can run on an older version of Windows, it will bring with it full VT support and this cursor change.

(incidentally, it works on Windows 8.1 and brings full VT support 😉)


default:
// Invalid argument should be ignored.
return true;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fair to treat parameter larger than 6 as a "success". I mean, why bother sending it to the connected terminal when we know it should be ignored.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well now that you mention it, technically we should probably be passing through any unknown parameters. The connected terminal is not necessarily WT, and it could potentially support values larger than 6. We were actually just discussing this in issue #7382 (comment). I don't think it's a big deal, but returning false here is probably better (assuming that doesn't cause any other problems).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I wasn't really sure about it. Let's try 'false' for this.

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is excellent. Thanks!

@DHowett DHowett added the AutoMerge Marked for automatic merge by the bot when requirements are met label Sep 4, 2020
@ghost ghost added the Issue-Task It's a feature request, but it doesn't really need a major design. label Sep 4, 2020
@ghost
Copy link

ghost commented Sep 4, 2020

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 7ab4d45 into microsoft:master Sep 4, 2020
@skyline75489 skyline75489 deleted the chesterliu/dev/decscusr-0 branch September 22, 2020 10:31
@ghost
Copy link

ghost commented Sep 22, 2020

🎉Windows Terminal Preview v1.4.2652.0 has been released which incorporates this pull request.:tada:

Handy links:

@younger-1
Copy link

younger-1 commented Feb 15, 2022

I don't think this actually fixes #1604 as vim does not attempt to restore cursor shape on exit. So..what do you guys think?

neovim and vim both do not restore cursor on exit if without configuring vimrc...

@ubaldot
Copy link

ubaldot commented Sep 19, 2024

I don't think this actually fixes #1604 as vim does not attempt to restore cursor shape on exit. So..what do you guys think?

neovim and vim both do not restore cursor on exit if without configuring vimrc...

I bumped into the same issue: shall I then explicitly use au VimLeave * set guicursor=a:hor10-blinkon1in my vimrc to get my cursor back?

Also, I have noticed that when accessing Vim the cursor won't take the color of the used colorscheme. Any idea why and how to fix it?

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-VT Virtual Terminal sequence support AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Task It's a feature request, but it doesn't really need a major design. Product-Conhost For issues in the Console codebase Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider supporting [extension to VT,] DECSCUSR "0" to restore cursor to user default to help vim/others
7 participants