starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

It should be possible to select a line including the linebreak #14800

New Issue
Closed
opened 2026-01-31 04:19:49 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 04:19:49 +00:00
Owner
Copy Link

Originally created by @SpecLad on GitHub (Aug 5, 2021).

Description of the new feature/enhancement

Look at this screenshot:

terminal-selection

Here I have selected some text by clicking where the blue dot is and dragging to where the green dot is. Even though my cursor at the end was to the left of the "g", the "g" was still selected. If I copy the selected text, the contents of the clipboard will be abcdef\ng.

This leaves no way to put abcdef\n on the clipboard. Even if you select the entire first line by dragging the cursor across the width of the window and copy, the clipboard will only contain abcdef.

I propose that the selection mechanism is changed so that if you end the drag to the left of the first character of the next line, then the line break is selected and the first character isn't.

Being able to copy a line with the linebreak (and without junk at the end) would be useful. You could then insert that line into a text editor between two other lines and not have to fix up the formatting afterwards.

I'm filing this as a feature request and not a bug, since I've no way to tell if the current behavior is intentional or not, but I'd like this behavior changed regardless.

Proposed technical implementation details (optional)

Originally created by @SpecLad on GitHub (Aug 5, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement Look at this screenshot: ![terminal-selection](https://user-images.githubusercontent.com/2391761/128411239-ef08cb24-2585-4912-b1ac-8bd4dc2ede3a.png) Here I have selected some text by clicking where the blue dot is and dragging to where the green dot is. Even though my cursor at the end was to the left of the "g", the "g" was still selected. If I copy the selected text, the contents of the clipboard will be `abcdef\ng`. This leaves no way to put `abcdef\n` on the clipboard. Even if you select the entire first line by dragging the cursor across the width of the window and copy, the clipboard will only contain `abcdef`. I propose that the selection mechanism is changed so that if you end the drag to the left of the first character of the next line, then the line break is selected and the first character isn't. Being able to copy a line with the linebreak (and without junk at the end) would be useful. You could then insert that line into a text editor between two other lines and not have to fix up the formatting afterwards. I'm filing this as a feature request and not a bug, since I've no way to tell if the current behavior is intentional or not, but I'd like this behavior changed regardless. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-31 04:19:49 +00:00
claunia commented 2026-01-31 04:19:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 5, 2021):

I think this is the same underlying issues as #10871. I think @DHowett has an idea of where the duplicate is earlier in the backlog, so I'll let him redirect that other bug (and this one) to the real root cause.

/dup #10871

@zadjii-msft commented on GitHub (Aug 5, 2021): I think this is the same underlying issues as #10871. I think @DHowett has an idea of where the duplicate is earlier in the backlog, so I'll let him redirect that other bug (and this one) to the real root cause. /dup #10871
claunia commented 2026-01-31 04:19:51 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 5, 2021):

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 commented on GitHub (Aug 5, 2021): 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!
claunia commented 2026-01-31 04:19:51 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Aug 6, 2021):

This goes way back. See #5099. It's one of the more annoying quirks of Windows Terminal and it keeps getting kicked down the road.

@vefatica commented on GitHub (Aug 6, 2021): This goes way back. See #5099. It's one of the more annoying quirks of Windows Terminal and it keeps getting kicked down the road.
claunia commented 2026-01-31 04:19:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2021):

@vefatica Whether a cell becomes "selected" when you move your mouse across the center of the cell or not has nothing to do with whether newlines are included in selection.

There's two problems here:

  1. Terminal occasionally mis-wraps lines. People report that their lines flow together and newlines are ignored. This is a bug, and we fix instances of it where we can. Nothing has been kicked down the road. That is not what this issue, or #10871, are reporting.
  2. People want the righthand side of the screen, where content has not been written, to be considered empty. When an application writes a hard line break, they want selection off the right side of the text to include the hard line break. This is what this issue, and #10871, are requesting.

For (1), again, nothing has been kicked down the road.

For (2), we need to nearly completely rearchitect our text buffer to fix things like #32 ("we don't know where a line ends"), which we're tracking in #8000. Work on that is ongoing¹, but poses a significant compatibility risk to people like you who write unusual TCC plugins that manipulate the raw content of the console buffer. Why? Because it's a full rewrite of the entire console buffer.

Work isn't being "kicked down the road" here insomuch as it is being carefully and cautiously approached by the stewards of console app compatibility on Windows.

¹ The history on that branch goes back 10 days, but work began in late December 2020.

@DHowett commented on GitHub (Aug 6, 2021): @vefatica Whether a cell becomes "selected" when you move your mouse across the center of the cell or not has nothing to do with whether newlines are included in selection. There's two problems here: 1. Terminal occasionally mis-wraps lines. People report that their lines flow together and newlines are ignored. This is a bug, and we fix instances of it where we can. Nothing has been kicked down the road. _That is not what this issue, or #10871, are reporting._ 2. People want the righthand side of the screen, where content has not been written, to be considered _empty_. When an application writes a hard line break, they want selection off the right side of the text to include the hard line break. _This is what this issue, and #10871, are requesting._ For (1), again, nothing has been kicked down the road. For (2), we need to nearly completely rearchitect our text buffer to fix things like #32 ("we don't know where a line ends"), which we're tracking in #8000. Work on that is [ongoing](https://github.com/microsoft/terminal/commits/dev/duhowett/hax/rle-row)¹, but poses a significant compatibility risk to people like you who write unusual TCC plugins that manipulate the raw content of the console buffer. Why? Because it's a full rewrite of the entire console buffer. Work isn't being "kicked down the road" here insomuch as it is being carefully and cautiously approached by the stewards of console app compatibility on Windows. ¹ The history on that branch goes back 10 days, but work began in late December 2020.
claunia commented 2026-01-31 04:19:51 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Aug 6, 2021):

Thanks for the response @DHowett. I haven't considered carefully, or followed, the issues you mentioned (and related ones). It's just that this issue targets my gripe (the automatic selection of the first character of the next line) rather succinctly.

@vefatica commented on GitHub (Aug 6, 2021): Thanks for the response @DHowett. I haven't considered carefully, or followed, the issues you mentioned (and related ones). It's just that this issue targets my gripe (the automatic selection of the first character of the next line) rather succinctly.
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-Feature 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#14800
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?