Win+Shift+S dismisses the selection #12073

@Don-Vito commented on GitHub (Jan 14, 2021):

@zadjii-msft - I believe this has the same root-cause as in https://github.com/microsoft/terminal/issues/5366: we clear selection and scroll almost upon every input, no matter if it results in any kind of buffer update.

I was always wondering, why are we cleaning selection in _TrySendKeyEvent, and do not wait for onReceiveOutputFn. I mean, does the user expect the selection to be preserved when a new output appears?

@Don-Vito commented on GitHub (Jan 14, 2021): @zadjii-msft - I believe this has the same root-cause as in https://github.com/microsoft/terminal/issues/5366: we clear selection and scroll almost upon every input, no matter if it results in any kind of buffer update. I was always wondering, why are we cleaning selection in `_TrySendKeyEvent`, and do not wait for `onReceiveOutputFn`. I mean, does the user expect the selection to be preserved when a new output appears?

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jan 15, 2021):

If I have scrolled back and the new output is coming to a line that is not even currently visible, then I surely expect the selection to be preserved.

@KalleOlaviNiemitalo commented on GitHub (Jan 15, 2021): If I have scrolled back and the new output is coming to a line that is not even currently visible, then I surely expect the selection to be preserved.

claunia commented

@zadjii-msft commented on GitHub (Jan 15, 2021):

It probably does have the same root cause. I knew this felt familiar, I guess we never really resolved that one.

why are we cleaning selection in _TrySendKeyEvent, and do not wait for onReceiveOutputFn. I mean, does the user expect the selection to be preserved when a new output appears?

I'm not sure there's an explicit reason - I think we were mostly trying to copy the way conhost worked.

It does kinda seem like output is a application-initiated event, while making a selection and entering input are user-initiated. You know, now that I've typed that up I'm not sure that has anything to do with it. But I do agree that we'd want to keep the selection when new output arrives. That does just make the problem tricky, cause it's hard to know when a key actually resulted in output.

@zadjii-msft commented on GitHub (Jan 15, 2021): It probably does have the same root cause. I knew this felt familiar, I guess we never really resolved that one. > why are we cleaning selection in `_TrySendKeyEvent`, and do not wait for `onReceiveOutputFn`. I mean, does the user expect the selection to be preserved when a new output appears? I'm not sure there's an explicit reason - I think we were mostly trying to copy the way conhost worked. It does kinda seem like output is a application-initiated event, while making a selection and entering input are user-initiated. You know, now that I've typed that up I'm not sure that has anything to do with it. But I do agree that we'd want to keep the selection when new output arrives. That does just make the problem tricky, cause it's hard to know when a key actually resulted in output.

claunia commented

@Don-Vito commented on GitHub (Jan 15, 2021):

@zadjii-msft - yeah. Makes sense. The question is can we somehow predict if some input will result in buffer change. I mean we can definitely do better and not to clear the selection before we know a sequence is sent to the connection.
However, in this case I guess the sequence is sent.

@Don-Vito commented on GitHub (Jan 15, 2021): @zadjii-msft - yeah. Makes sense. The question is can we somehow predict if some input will result in buffer change. I mean we can definitely do better and not to clear the selection before we know a sequence is sent to the connection. However, in this case I guess the sequence is sent.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jan 15, 2021):

Can you make an exception just for key combinations that involve the Windows key?

@KalleOlaviNiemitalo commented on GitHub (Jan 15, 2021): Can you make an exception just for key combinations that involve the Windows key?

claunia commented

@imaginary-person commented on GitHub (Feb 8, 2021):

@zadjii-msft: Hey Mike, currently it seems hard to figure out which Easy-Starter issues are up for grabs. For instance, it looks like your team is working on this one. Please let me know if any Easy-Starter issue is yet to be worked on. Thanks!

@imaginary-person commented on GitHub (Feb 8, 2021): @zadjii-msft: Hey Mike, currently it seems hard to figure out which `Easy-Starter` issues are up for grabs. For instance, it looks like your team is working on this one. Please let me know if any `Easy-Starter` issue is yet to be worked on. Thanks!

claunia commented

@zadjii-msft commented on GitHub (Feb 8, 2021):

Nope, no one on the team is currently working on this. Usually when someone starts working on a fix, they'll assign it to themselves.

We'll throw everything in milestones, regardless of if someone is assigned or not. By putting this in the 2.0 milestone, that's just us saying "this needs to be fixed before 2.0". If no one in the community gets to it by then, one of us will need to do it ourselves.

We're still trying to work out which "Help Wanted" issues are really "Easy Starter"s or not. I'm not confident that we've really figured that out quite yet, but this one shouldn't be too bad. IIRC we only started using the "Easy Starter" label a few months ago, so there's probably a good number of older "Help Wanted" issues that should also be tagged with "Easy Starter". I'll make an effort later this week to try and go through and update the labels of older issues.

If you want to take a look at this (or anything else), I'd be happy to assign it to you. Let me know!

@zadjii-msft commented on GitHub (Feb 8, 2021): Nope, no one on the team is currently working on this. Usually when someone starts working on a fix, they'll assign it to themselves. We'll throw _everything_ in milestones, regardless of if someone is assigned or not. By putting this in the 2.0 milestone, that's just us saying "this needs to be fixed before 2.0". If no one in the community gets to it by then, one of us will need to do it ourselves. We're still trying to work out which "Help Wanted" issues are really "Easy Starter"s or not. I'm not confident that we've really figured that out quite yet, but this one shouldn't be _too_ bad. IIRC we only started using the "Easy Starter" label a few months ago, so there's probably a good number of older "Help Wanted" issues that should _also_ be tagged with "Easy Starter". I'll make an effort later this week to try and go through and update the labels of older issues. If you want to take a look at this (or anything else), I'd be happy to assign it to you. Let me know!

claunia commented

@Don-Vito commented on GitHub (Feb 8, 2021):

@imaginary-person, @zadjii-msft - I guess this one is not a really easy starter.. at least not yet.. we have not still figured out how to approach it product-wise.

@zadjii-msft - if you agree with the approach of ignoring Win-key combinations that @KalleOlaviNiemitalo suggested, then it can be a good easy-starter for sure.

@Don-Vito commented on GitHub (Feb 8, 2021): @imaginary-person, @zadjii-msft - I guess this one is not a really easy starter.. at least not yet.. we have not still figured out how to approach it product-wise. @zadjii-msft - if you agree with the approach of ignoring `Win`-key combinations that @KalleOlaviNiemitalo suggested, then it can be a good easy-starter for sure.

claunia commented

@imaginary-person commented on GitHub (Feb 8, 2021):

@zadjii-msft & @Don-Vito, thanks for the clarification!

@imaginary-person commented on GitHub (Feb 8, 2021): @zadjii-msft & @Don-Vito, thanks for the clarification!

claunia commented

@zadjii-msft commented on GitHub (Feb 8, 2021):

if you agree with the approach of ignoring Win-key combinations that KalleOlaviNiemitalo suggested, then it can be a good easy-starter for sure.

Seems like a sensible enough solution for now. Might as well not ignore an incremental improvement in the pursuit of perfection.

@zadjii-msft commented on GitHub (Feb 8, 2021): > if you agree with the approach of ignoring `Win`-key combinations that **KalleOlaviNiemitalo** suggested, then it can be a good easy-starter for sure. Seems like a sensible enough solution for now. Might as well not ignore an incremental improvement in the pursuit of perfection.

claunia commented

@Don-Vito commented on GitHub (Feb 8, 2021):

@zadjii-msft - can you please update the description then? 😊

@imaginary-person - I would be glad to assist if you want to work on this: it should be something like "do not dismiss selection if key combination contains win-key"

@Don-Vito commented on GitHub (Feb 8, 2021): @zadjii-msft - can you please update the description then? :blush: @imaginary-person - I would be glad to assist if you want to work on this: it should be something like "do not dismiss selection if key combination contains `win`-key"

claunia commented

@imaginary-person commented on GitHub (Feb 8, 2021):

@Don-Vito: Thanks in advance for your help! I'd ping you for help if I'd get stuck, or if I'd have any doubt.

@imaginary-person commented on GitHub (Feb 8, 2021): @Don-Vito: Thanks in advance for your help! I'd ping you for help if I'd get stuck, or if I'd have any doubt.

claunia commented

@ghost commented on GitHub (Mar 1, 2021):

:tada:This issue was addressed in #9163, which has now been successfully released as Windows Terminal v1.6.10571.0.🎉

Handy links:

@ghost commented on GitHub (Mar 1, 2021): :tada:This issue was addressed in #9163, which has now been successfully released as `Windows Terminal v1.6.10571.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.6.10571.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented