Revisit TerminalSelection to add tests, clean up, proper selection mechanics #1760

Closed
opened 2026-01-30 22:35:49 +00:00 by claunia · 5 comments
Owner

Originally created by @carlos-zamora on GitHub (Jun 19, 2019).

Originally assigned to: @carlos-zamora on GitHub.

More of a mental note of all the misc. selection stuff I need to do. Hopefully I can get this in very soon so that we can verify that nothing was broken.

  • Add testing for the following scenarios:
    • endSelectionPosition being located out of bounds
  • _GetSelectionRects() clean up
    • the pre-processing part is just a bit nasty now. There should be a way to simplify it. Need to be careful with testing this though.
  • Proper selection mechanics
    • when your endSelectionPosition is out of bounds vertically, the x-position should still update, but the y-position should be at the boundary
    • when your endSelectionPosition is out of bounds horizontally, the y-position should still update, but the y-position should be at the buffer boundary
    • this is particularly important for #1247. As the y-position must be detected to be out of the bounds, so that's still valid. But it should be displayed as updating the x-position.
Originally created by @carlos-zamora on GitHub (Jun 19, 2019). Originally assigned to: @carlos-zamora on GitHub. More of a mental note of all the misc. selection stuff I need to do. Hopefully I can get this in very soon so that we can verify that nothing was broken. - [x] Add testing for the following scenarios: - [x] `endSelectionPosition` being located out of bounds - [ ] `_GetSelectionRects()` clean up - the pre-processing part is just a bit nasty now. There should be a way to simplify it. Need to be careful with testing this though. - [x] Proper selection mechanics - when your `endSelectionPosition` is out of bounds **vertically**, the x-position should still update, but the y-position should be at the boundary - when your `endSelectionPosition` is out of bounds **horizontally**, the y-position should still update, but the y-position should be at the **buffer** boundary - this is particularly important for #1247. As the y-position must be detected to be out of the bounds, so that's still valid. But it should be displayed as updating the x-position.
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 14, 2019):

  • no need for us to track the start and end Y-offsets separately; they are generally the same (?)
  • concern about the logic being fragmented into a few different functions: chunk selections are expanded during GetSelectionRects instead of during selection (?)
@DHowett-MSFT commented on GitHub (Aug 14, 2019): * [x] no need for us to track the start and end Y-offsets separately; they are generally the same (?) * [ ] concern about the logic being fragmented into a few different functions: chunk selections are expanded during _GetSelectionRects_ instead of during selection (?)
Author
Owner

@carlos-zamora commented on GitHub (Aug 16, 2019):

  • IsAreaSelected and IsSelectionActive are the SAME THING
@carlos-zamora commented on GitHub (Aug 16, 2019): - [x] `IsAreaSelected` and `IsSelectionActive` are the SAME THING
Author
Owner

@carlos-zamora commented on GitHub (Aug 17, 2019):

  • IsAreaSelected and IsSelectionActive are the SAME THING

So, this one's on me. I created IsAreaSelected() in #1691 when I made some changes to IRenderData. This can actually get resolved in #2296 since I'm already touching that area of the code.

@carlos-zamora commented on GitHub (Aug 17, 2019): > * [x] `IsAreaSelected` and `IsSelectionActive` are the SAME THING So, this one's on me. I created `IsAreaSelected()` in #1691 when I made some changes to `IRenderData`. This can actually get resolved in #2296 since I'm already touching that area of the code.
Author
Owner

@carlos-zamora commented on GitHub (Aug 20, 2019):

  • concern about the logic being fragmented into a few different functions: chunk selections are expanded during GetSelectionRects instead of during selection (?)

I'm thinking now that this might be OK. Keyboard selection would just set the anchors to whatever these functions return. That'll allow us to reuse the same function for the weird box selections that cover wide glyphs and words (on double click selections).

@carlos-zamora commented on GitHub (Aug 20, 2019): > * [ ] concern about the logic being fragmented into a few different functions: chunk selections are expanded during _GetSelectionRects_ instead of during selection (?) I'm thinking now that this might be OK. Keyboard selection would just set the anchors to whatever these functions return. That'll allow us to reuse the same function for the weird box selections that cover wide glyphs and words (on double click selections).
Author
Owner

@ghost commented on GitHub (Sep 24, 2019):

:tada:This issue was addressed in #2511, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.🎉

Handy links:

@ghost commented on GitHub (Sep 24, 2019): :tada:This issue was addressed in #2511, which has now been successfully released as `Windows Terminal Preview v0.5.2661.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.5.2661.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1760