starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Unable to select text in pagination mode #23154

New Issue
Closed
opened 2026-01-31 08:33:50 +00:00 by claunia · 15 comments
claunia commented 2026-01-31 08:33:50 +00:00
Owner
Copy Link

Originally created by @compnerd on GitHub (Apr 14, 2025).

Windows Terminal version

1.22.10731.0

Windows build number

10.0.26100.0

Other Software

No response

Steps to reproduce

Using git log (which uses less as a pager as per default), I am unable to simply double click on the commit hash to select the text. Attempting to do so will result in re-rendering the entire terminal continuously for a while. I've noticed that ESC0D will sometimes appear in the bottom left corner, making me believe that this is a bug in the ANSI sequence parser. It seems that there would be something odd going on with the CSI interpreter, possibly mishandling the initial byte?

This seems to have triggered somewhat recently, though I cannot pin down whether it was a WT update or Patch Tuesday update.

The canary build seems to reproduce this as well.

Note that it helps to have a particularly large terminal (e.g. full screen).

Expected Behavior

No response

Actual Behavior

The terminal becomes non-responsive, redrawing the terminal.

Originally created by @compnerd on GitHub (Apr 14, 2025). ### Windows Terminal version 1.22.10731.0 ### Windows build number 10.0.26100.0 ### Other Software _No response_ ### Steps to reproduce Using `git log` (which uses `less` as a pager as per default), I am unable to simply double click on the commit hash to select the text. Attempting to do so will result in re-rendering the entire terminal continuously for a while. I've noticed that `ESC0D` will sometimes appear in the bottom left corner, making me believe that this is a bug in the ANSI sequence parser. It seems that there would be something odd going on with the CSI interpreter, possibly mishandling the initial byte? This seems to have triggered somewhat recently, though I cannot pin down whether it was a WT update or Patch Tuesday update. The canary build seems to reproduce this as well. Note that it helps to have a particularly large terminal (e.g. full screen). ### Expected Behavior _No response_ ### Actual Behavior The terminal becomes non-responsive, redrawing the terminal.
claunia added the Issue-BugResolution-Duplicate labels 2026-01-31 08:33:50 +00:00
claunia commented 2026-01-31 08:33:51 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Apr 15, 2025):

I suspect a related exhibition of the issue is that if you type a partial command on the terminal, and then attempt to highlight text, instead of highlighting the text, the cursor is moved to the beginning of the line.

@compnerd commented on GitHub (Apr 15, 2025): I suspect a related exhibition of the issue is that if you type a partial command on the terminal, and then attempt to highlight text, instead of highlighting the text, the cursor is moved to the beginning of the line.
claunia commented 2026-01-31 08:33:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 16, 2025):

Hey @compnerd, nice to see you around these parts 🙂

Just a couple quick differential diagnostic questions...

  • If you use Shift+click, are you able to select text again?
  • Would you be able to grab a debug tap trace/?

I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode and then enables VT input...) and doesn't know what to do with what it's getting back.

@DHowett commented on GitHub (Apr 16, 2025): Hey @compnerd, nice to see you around these parts 🙂 Just a couple quick differential diagnostic questions... - If you use <kbd>Shift+</kbd>click, are you able to select text again? - Would you be able to grab a [debug tap] trace/? I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode _and then enables VT input..._) and doesn't know what to do with what it's getting back. [debug tap]: https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#enabling-the-debug-tap
claunia commented 2026-01-31 08:33:51 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Apr 16, 2025):

Hey @compnerd, nice to see you around these parts 🙂

Hey @DHowett, great to see that you're still involved in Terminal! 😄

Just a couple quick differential diagnostic questions...

  • If you use Shift+click, are you able to select text again?

I think that I didn't clearly explain the issue, sorry. It will let me select text again, just only after it has completed repainting the terminal a large number of times. You can identify this process as being complete because the terminal is fully rendered and scrolled up a line (which matches the CSI of 0D). But, just to verify, Shift+click doesn't select any text during the re-draw phase.

One thing that is interesting is that once this has occurred, it will function properly subsequently. So there is something more interesting going on, possibly with state initialisation?

  • Would you be able to grab a debug tap trace/?

Well, the instructions seem complete enough, let me try to do that.

I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode and then enables VT input...) and doesn't know what to do with what it's getting back.

Hmm, I didn't think of that. You think that this could be related to DECELR? That would allow it to read the scroll "button" (wheel) to allow pagination.

@compnerd commented on GitHub (Apr 16, 2025): > Hey [@compnerd](https://github.com/compnerd), nice to see you around these parts 🙂 Hey @DHowett, great to see that you're still involved in Terminal! 😄 > Just a couple quick differential diagnostic questions... > > * If you use Shift+click, are you able to select text again? I think that I didn't clearly explain the issue, sorry. It will let me select text again, just only _after_ it has completed repainting the terminal a large number of times. You can identify this process as being complete because the terminal is fully rendered and scrolled up a line (which matches the CSI of 0D). But, just to verify, Shift+click doesn't select any text during the re-draw phase. One thing that is interesting is that once this has occurred, it will function properly subsequently. So there is something more interesting going on, possibly with state initialisation? > * Would you be able to grab a [debug tap](https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#enabling-the-debug-tap) trace/? Well, the instructions seem complete enough, let me try to do that. > I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode _and then enables VT input..._) and doesn't know what to do with what it's getting back. Hmm, I didn't think of that. You think that this could be related to DECELR? That would allow it to read the scroll "button" (wheel) to allow pagination.
claunia commented 2026-01-31 08:33:52 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Apr 16, 2025):

  • Would you be able to grab a debug tap trace/?

Well, the instructions seem complete enough, let me try to do that.

Well, that doesn't seem to work very well - it seems to truncate the buffer before I can get the interesting stuff due to the re-rendering.

@compnerd commented on GitHub (Apr 16, 2025): > > * Would you be able to grab a [debug tap](https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#enabling-the-debug-tap) trace/? > > Well, the instructions seem complete enough, let me try to do that. Well, that doesn't seem to work very well - it seems to truncate the buffer before I can get the interesting stuff due to the re-rendering.
claunia commented 2026-01-31 08:33:52 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Apr 16, 2025):

tap.txt

Okay, I used a different repository which doesn't have as big of a history, it actually is interesting as this is the second exhibition of the issue: it has already exited the pager (less). However, the text selection seems to still trigger the issue. I'm attaching the tap as an attachment here.

@compnerd commented on GitHub (Apr 16, 2025): [tap.txt](https://github.com/user-attachments/files/19785125/tap.txt) Okay, I used a different repository which doesn't have as big of a history, it actually is interesting as this is the second exhibition of the issue: it has already exited the pager (`less`). However, the text selection seems to still trigger the issue. I'm attaching the tap as an attachment here.
claunia commented 2026-01-31 08:33:52 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Apr 22, 2025):

It seems that yet another exhibition of this issue is if you scroll up, trying to highlight any text will scroll and then highlight, preventing copying any text on any row above the current viewport.

@compnerd commented on GitHub (Apr 22, 2025): It seems that yet another exhibition of this issue is if you scroll up, trying to highlight any text will scroll and then highlight, preventing copying any text on any row above the current viewport.
claunia commented 2026-01-31 08:33:53 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (May 12, 2025):

Any suggestions on what to do here to dig into this further @DHowett? It is really making Terminal nearly impossible to use for development work.

@compnerd commented on GitHub (May 12, 2025): Any suggestions on what to do here to dig into this further @DHowett? It is really making Terminal nearly impossible to use for development work.
claunia commented 2026-01-31 08:33:53 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 12, 2025):

If you have multiple PCs, does this issue also occur on your other machines? We sometimes get reports from people having a laggy experience, where it then turns out they have a corporate anti-virus installed. They can sometimes interfere with us processing the output in a timely manner.

Because the problem is that we have 1 mutex that protects the terminal state. That mutex gets acquired by the:

  • output / VT parser
  • text renderer
  • UI thread when selecting text

If any of the 3 take an unusually long time to process something, this would explain why you find it difficult to select text. Regarding each respective point:

  • That version of Windows Terminal can process VT somewhere in the order of 50-100MB/s depending on your CPU. The maximum chunk size for reading text is somewhere around 128KiB. Thus, the worst-case scenario is that the terminal freezes for ~3ms per read.
  • The text renderer is highly optimized for performance and should run at around 100 FPS on a low end mobile GPU. Only a part of that duration is spent holding the lock. I estimate it to be less than half the time, so let's say 5ms.
  • The UI thread only holds the lock to update the selection data, which takes somewhere around 10ns.

So, theoretically each location that holds the mutex should hold it for reasonably short periods of time. This means, even if you have tons of VT output, and slow text rendering going on simultaneously, you should still be able to select text fluidly. Something else must be going on (could also be another bug in Windows Terminal).

If it's simple for you to do so, could you please capture a screen recording of the issue? Just so we're all on the same page.

@lhecker commented on GitHub (May 12, 2025): If you have multiple PCs, does this issue also occur on your other machines? We sometimes get reports from people having a laggy experience, where it then turns out they have a corporate anti-virus installed. They can sometimes interfere with us processing the output in a timely manner. Because the problem is that we have 1 mutex that protects the terminal state. That mutex gets acquired by the: * output / VT parser * text renderer * UI thread when selecting text If any of the 3 take an unusually long time to process something, this would explain why you find it difficult to select text. Regarding each respective point: * That version of Windows Terminal can process VT somewhere in the order of 50-100MB/s depending on your CPU. The maximum chunk size for reading text is somewhere around 128KiB. Thus, the worst-case scenario is that the terminal freezes for ~3ms per read. * The text renderer is highly optimized for performance and should run at around 100 FPS on a low end mobile GPU. Only a part of that duration is spent holding the lock. I estimate it to be less than half the time, so let's say 5ms. * The UI thread only holds the lock to update the selection data, which takes somewhere around 10ns. So, theoretically each location that holds the mutex should hold it for reasonably short periods of time. This means, even if you have tons of VT output, and slow text rendering going on simultaneously, you should still be able to select text fluidly. Something else must be going on (could also be another bug in Windows Terminal). If it's simple for you to do so, could you please capture a screen recording of the issue? Just so we're all on the same page.
claunia commented 2026-01-31 08:33:53 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (May 12, 2025):

If you have multiple PCs, does this issue also occur on your other machines? We sometimes get reports from people having a laggy experience, where it then turns out they have a corporate anti-virus installed. They can sometimes interfere with us processing the output in a timely manner.

The only antivirus that I have installed is Windows Defender.

Because the problem is that we have 1 mutex that protects the terminal state. That mutex gets acquired by the:

  • output / VT parser
  • text renderer
  • UI thread when selecting text

If any of the 3 take an unusually long time to process something, this would explain why you find it difficult to select text. Regarding each respective point:

  • That version of Windows Terminal can process VT somewhere in the order of 50-100MB/s depending on your CPU. The maximum chunk size for reading text is somewhere around 128KiB. Thus, the worst-case scenario is that the terminal freezes for ~3ms per read.
  • The text renderer is highly optimized for performance and should run at around 100 FPS on a low end mobile GPU. Only a part of that duration is spent holding the lock. I estimate it to be less than half the time, so let's say 5ms.
  • The UI thread only holds the lock to update the selection data, which takes somewhere around 10ns.

So, theoretically each location that holds the mutex should hold it for reasonably short periods of time. This means, even if you have tons of VT output, and slow text rendering going on simultaneously, you should still be able to select text fluidly. Something else must be going on (could also be another bug in Windows Terminal).

If it's simple for you to do so, could you please capture a screen recording of the issue? Just so we're all on the same page.

I don't think that this is a rendering issue per se ... if you look at the log, there is a large number of CSI scroll events, so I suspect that it is unnecessarily adjusting the cursor position and view port for the text. This gives the impression of freezing as the cursor rehoming in a tight loop prevents the other operations from actually getting processed. Note that at the very end, the selected bounds are on the last frame while the text itself has scrolled out of the view port resulting in some arbitrary content being highlighted. I'll try to see if I can create a recording if you think that is more useful.

@compnerd commented on GitHub (May 12, 2025): > If you have multiple PCs, does this issue also occur on your other machines? We sometimes get reports from people having a laggy experience, where it then turns out they have a corporate anti-virus installed. They can sometimes interfere with us processing the output in a timely manner. The only antivirus that I have installed is Windows Defender. > Because the problem is that we have 1 mutex that protects the terminal state. That mutex gets acquired by the: > > * output / VT parser > * text renderer > * UI thread when selecting text > > If any of the 3 take an unusually long time to process something, this would explain why you find it difficult to select text. Regarding each respective point: > > * That version of Windows Terminal can process VT somewhere in the order of 50-100MB/s depending on your CPU. The maximum chunk size for reading text is somewhere around 128KiB. Thus, the worst-case scenario is that the terminal freezes for ~3ms per read. > * The text renderer is highly optimized for performance and should run at around 100 FPS on a low end mobile GPU. Only a part of that duration is spent holding the lock. I estimate it to be less than half the time, so let's say 5ms. > * The UI thread only holds the lock to update the selection data, which takes somewhere around 10ns. > > So, theoretically each location that holds the mutex should hold it for reasonably short periods of time. This means, even if you have tons of VT output, and slow text rendering going on simultaneously, you should still be able to select text fluidly. Something else must be going on (could also be another bug in Windows Terminal). > > If it's simple for you to do so, could you please capture a screen recording of the issue? Just so we're all on the same page. I don't think that this is a rendering issue per se ... if you look at the log, there is a large number of CSI scroll events, so I suspect that it is unnecessarily adjusting the cursor position and view port for the text. This gives the impression of freezing as the cursor rehoming in a tight loop prevents the other operations from actually getting processed. Note that at the very end, the selected bounds are on the last frame while the text itself has scrolled out of the view port resulting in some arbitrary content being highlighted. I'll try to see if I can create a recording if you think that is more useful.
claunia commented 2026-01-31 08:33:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 13, 2025):

So, the ESC0D is a bit of a red herring. That's output from less after it receives SS3 D (where SS3 is ESC O.)

That is the correct and complete encoding for cursor left in Application Keys mode (DECCKM set).

In your tap trace, I see that less is requesting DECCKM with termcap ks (set $env:LESS_TERMCAP_DEBUG=1 to see it), so that checks out. This is just a symptom though.

As you've identified, something is generating an inordinate amount of input into your terminal session of the following two key events:

  • ␛[37;75;0;1;0;1_

    • Vk: VK_LEFT
    • Sc: 75
    • Uc: 0
    • Kd: down
    • Cs: 0

  • ␛[37;75;0;1;0;1_

    • Vk: VK_LEFT
    • Sc: 75
    • Uc: 0
    • Kd: up
    • Cs: 0

By my count, 8346 of them... which is consistent with your observed behavior.

There are three instances in which Terminal will emit ␛[37;75;0;1;0;1_ (in this specific format) into the input buffer:

  • You pressed the left arrow key.
  • Some software pressed the left arrow key on your behalf.
  • You've enabled the experimental "reposition cursor with click" feature.

Considering that there are ~8,300 combined left arrow presses and releases (4,173 presses), and that your tap contains a cursor position sequence indicating Y=47 X=35, I can only assume that your buffer is... let's conservatively guess 88x47.

That experimental feature works only on input lines and by literally trying to move the cursor left or right the same logical number of cells as appear to be occupied on the screen.

So, clicking somewhere in the top left of the screen will try to move the cursor left ~4,173 times.

I would say that we should disable the cursor repositioning feature when the alternate screen buffer is in use (as it is in less) but that would break tmux.

It's an experimental feature, though, so we can play with the heuristics a bit.

@DHowett commented on GitHub (May 13, 2025): So, the `ESC0D` is a bit of a red herring. That's output _from_ less after it receives `SS3 D` (where `SS3` is `ESC O`.) That is the correct and complete encoding for cursor left in Application Keys mode (`DECCKM` set). In your tap trace, I see that less is requesting `DECCKM` with termcap `ks` (set `$env:LESS_TERMCAP_DEBUG=1` to see it), so that checks out. This is just a symptom though. As you've identified, something is generating an inordinate amount of input _into_ your terminal session of the following two key events: * `␛[37;75;0;1;0;1_` * `Vk`: VK_LEFT * `Sc`: 75 * `Uc`: 0 * `Kd`: down * `Cs`: 0 * `␛[37;75;0;1;0;1_` * `Vk`: VK_LEFT * `Sc`: 75 * `Uc`: 0 * `Kd`: up * `Cs`: 0 By my count, 8346 of them... which is consistent with your observed behavior. There are three instances in which Terminal will emit `␛[37;75;0;1;0;1_` (in this specific format) into the input buffer: - You pressed the left arrow key. - Some software pressed the left arrow key on your behalf. - You've enabled the experimental "reposition cursor with click" feature. Considering that there are ~8,300 combined left arrow presses and releases (4,173 presses), and that your tap contains a cursor position sequence indicating Y=47 X=35, I can only assume that your buffer is... let's conservatively guess 88x47. That experimental feature works only on input lines and by literally trying to move the cursor left or right the same logical number of cells as appear to be occupied on the screen. So, clicking somewhere in the top left of the screen will try to move the cursor left ~4,173 times. --- I would say that we should disable the cursor repositioning feature when the alternate screen buffer is in use (as it is in less) but that would break tmux. It's an experimental feature, though, so we can play with the heuristics a bit.
claunia commented 2026-01-31 08:33:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 13, 2025):

For now, though, try disabling it :)

@DHowett commented on GitHub (May 13, 2025): For now, though, try disabling it :)
claunia commented 2026-01-31 08:33:55 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (May 13, 2025):

I tried to glance through the tap trace but wasn't able to really split up the sequences even with the python script.

So, the ESC0D is a bit of a red herring. That's output from less after it receives SS3 D (where SS3 is ESC O.)

That is the correct and complete encoding for cursor left in Application Keys mode (DECCKM set).

Agreed that the output of ESC0D is from less, but I'm not entirely sure if it is entirely a red herring. It is just a symptom, not the cause of course.

In your tap trace, I see that less is requesting DECCKM with termcap ks (set $env:LESS_TERMCAP_DEBUG=1 to see it), so that checks out. This is just a symptom though.

As you've identified, something is generating an inordinate amount of input into your terminal session of the following two key events:

  • ␛[37;75;0;1;0;1_

    • Vk: VK_LEFT
    • Sc: 75
    • Uc: 0
    • Kd: down
    • Cs: 0

  • ␛[37;75;0;1;0;1_

    • Vk: VK_LEFT
    • Sc: 75
    • Uc: 0
    • Kd: up
    • Cs: 0

By my count, 8346 of them... which is consistent with your observed behavior.

Yeah, this doesn't seem to be a processing speed thing but rather overloading the processing.

There are three instances in which Terminal will emit ␛[37;75;0;1;0;1_ (in this specific format) into the input buffer:

  • You pressed the left arrow key.
  • Some software pressed the left arrow key on your behalf.
  • You've enabled the experimental "reposition cursor with click" feature.

Ugh, I had completely forgotten about the experimental feature🤦

Considering that there are ~8,300 combined left arrow presses and releases (4,173 presses), and that your tap contains a cursor position sequence indicating Y=47 X=35, I can only assume that your buffer is... let's conservatively guess 88x47.

That experimental feature works only on input lines and by literally trying to move the cursor left or right the same logical number of cells as appear to be occupied on the screen.

Oh, interesting! Why the preference for the simplistic approach (move cursor backwards) rather than something like the CUP CSI? At this point, that is pretty widely supported (including by Terminal). I suppose that the problem would be with more complex text layout and trying to map the position to a cell?

So, clicking somewhere in the top left of the screen will try to move the cursor left ~4,173 times.

I would say that we should disable the cursor repositioning feature when the alternate screen buffer is in use (as it is in less) but that would break tmux.

It's an experimental feature, though, so we can play with the heuristics a bit.

Verified that the experimental "reposition cursor with click" is indeed responsible. Interestingly enough, I think that I've seen some similar issues without the alternate buffer mode, though that may be an unclean exit from less not fully resetting the terminal parser state.

Thanks for identifying the issue though @DHowett!

@compnerd commented on GitHub (May 13, 2025): I tried to glance through the tap trace but wasn't able to really split up the sequences even with the python script. > So, the `ESC0D` is a bit of a red herring. That's output _from_ less after it receives `SS3 D` (where `SS3` is `ESC O`.) > > That is the correct and complete encoding for cursor left in Application Keys mode (`DECCKM` set). Agreed that the output of `ESC0D` is from `less`, but I'm not entirely sure if it is entirely a red herring. It is just a symptom, not the cause of course. > In your tap trace, I see that less is requesting `DECCKM` with termcap `ks` (set `$env:LESS_TERMCAP_DEBUG=1` to see it), so that checks out. This is just a symptom though. > > As you've identified, something is generating an inordinate amount of input _into_ your terminal session of the following two key events: > > * `␛[37;75;0;1;0;1_` > > * `Vk`: VK_LEFT > * `Sc`: 75 > * `Uc`: 0 > * `Kd`: down > * `Cs`: 0 > * `␛[37;75;0;1;0;1_` > > * `Vk`: VK_LEFT > * `Sc`: 75 > * `Uc`: 0 > * `Kd`: up > * `Cs`: 0 > > By my count, 8346 of them... which is consistent with your observed behavior. Yeah, this doesn't seem to be a processing speed thing but rather overloading the processing. > There are three instances in which Terminal will emit `␛[37;75;0;1;0;1_` (in this specific format) into the input buffer: > > * You pressed the left arrow key. > * Some software pressed the left arrow key on your behalf. > * You've enabled the experimental "reposition cursor with click" feature. Ugh, I had completely forgotten about the experimental feature🤦 > Considering that there are ~8,300 combined left arrow presses and releases (4,173 presses), and that your tap contains a cursor position sequence indicating Y=47 X=35, I can only assume that your buffer is... let's conservatively guess 88x47. > > That experimental feature works only on input lines and by literally trying to move the cursor left or right the same logical number of cells as appear to be occupied on the screen. Oh, interesting! Why the preference for the simplistic approach (move cursor backwards) rather than something like the CUP CSI? At this point, that is pretty widely supported (including by Terminal). I suppose that the problem would be with more complex text layout and trying to map the position to a cell? > So, clicking somewhere in the top left of the screen will try to move the cursor left ~4,173 times. > > I would say that we should disable the cursor repositioning feature when the alternate screen buffer is in use (as it is in less) but that would break tmux. > > It's an experimental feature, though, so we can play with the heuristics a bit. Verified that the experimental "reposition cursor with click" is indeed responsible. Interestingly enough, I think that I've seen some similar issues without the alternate buffer mode, though that may be an unclean exit from less not fully resetting the terminal parser state. Thanks for identifying the issue though @DHowett!
claunia commented 2026-01-31 08:33:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 13, 2025):

CUP CSI

So, the problem isn't one of getting the cursor position right inside terminal, it's communicating it to the shell. Moving the cursor ourselves is easy: we don't even need to write output for it. Moving it under the nose of the active line editor will, however, break that line editor terribly.

We have to let the shell in on the trick and get it to move the cursor so it can keep its document model in sync. Most such line editors are only expecting a handful of input sequences, and CUP is definitely not one of them. 🙂

This feature is a stopgap built to serve when shells don't have mouse support, so it has to make some assumptions. If we could write CUP and get shells to handle it, we could probably just get them to handle mouse input directly too.

@DHowett commented on GitHub (May 13, 2025): > CUP CSI So, the problem isn't one of getting the cursor position right _inside terminal_, it's communicating it to the shell. Moving the cursor ourselves is easy: we don't even need to write output for it. Moving it under the nose of the active line editor will, however, break that line editor terribly. We have to let the shell in on the trick and get _it_ to move the cursor so it can keep its document model in sync. Most such line editors are only expecting a handful of input sequences, and `CUP` is definitely not one of them. 🙂 This feature is a stopgap built to serve when shells don't have mouse support, so it has to make some assumptions. If we could write CUP and get shells to handle it, we could probably just get them to handle mouse input directly too.
claunia commented 2026-01-31 08:33:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 13, 2025):

Oh hey look this is /dup #17803

@zadjii-msft commented on GitHub (Aug 13, 2025): Oh hey look this is /dup #17803
claunia commented 2026-01-31 08:33:56 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Aug 13, 2025):

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!

@microsoft-github-policy-service[bot] commented on GitHub (Aug 13, 2025): 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! <!-- Policy app identification https://img.shields.io/static/v1?label=PullRequestIssueManagement. -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23154
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?