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

Block copy with the ALT+MOUSE unexpectedly wraps the copied text into a single string #9360

New Issue
Closed
opened 2026-01-31 01:52:37 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 01:52:37 +00:00
Owner
Copy Link

Originally created by @vblazhkun on GitHub (Jul 1, 2020).

Originally assigned to: @carlos-zamora on GitHub.

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 1.1.1671.0

Any other software?

- WSL Ubuntu 20.04 LTS

Steps to reproduce

  1. Use the default WT settings.
  2. Use the "copyOnSelect": true.
  3. Select a rectangular text block.
  4. Paste the selection.

image

Expected behavior

The block copy should leave a block as is (including the whitespace). There is an existing default setting in the schema ("singleLine": false), but, it seems, it applies for keyboard shortcuts solely.

image

Actual behavior

The block copy wraps everything to a single string.

image

Originally created by @vblazhkun on GitHub (Jul 1, 2020). Originally assigned to: @carlos-zamora on GitHub. # Environment ```none Windows build number: 10.0.18363.0 Windows Terminal version (if applicable): 1.1.1671.0 Any other software? - WSL Ubuntu 20.04 LTS ``` # Steps to reproduce 1. Use the default WT settings. 2. Use the `"copyOnSelect": true`. 3. Select a rectangular text block. 4. Paste the selection. ![image](https://user-images.githubusercontent.com/7956686/86185533-35502500-bb3f-11ea-8b87-add769c00f56.png) # Expected behavior The block copy should leave a block as is (including the whitespace). There is an existing default setting in the schema (`"singleLine": false`), but, it seems, it applies for keyboard shortcuts solely. ![image](https://user-images.githubusercontent.com/7956686/86185588-5c0e5b80-bb3f-11ea-93aa-64feb77934b3.png) # Actual behavior The block copy wraps everything to a single string. ![image](https://user-images.githubusercontent.com/7956686/86185568-4d27a900-bb3f-11ea-9248-99e7ba3fbf12.png)
claunia commented 2026-01-31 01:52:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 3, 2020):

You know what, we might accidentally be taking the line wrap state into account when we do block selection, where we absolutely should not.

/cc @carlos-zamora seem right?

@DHowett commented on GitHub (Jul 3, 2020): You know what, we might accidentally be taking the _line wrap state_ into account when we do block selection, where we absolutely should not. /cc @carlos-zamora seem right?
claunia commented 2026-01-31 01:52:38 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jul 3, 2020):

I don't think so but I can look into it a bit more.

What are you connected to in WSL Ubuntu? Vim?

@carlos-zamora commented on GitHub (Jul 3, 2020): I don't think so but I can look into it a bit more. What are you connected to in WSL Ubuntu? Vim?
claunia commented 2026-01-31 01:52:39 +00:00
Author
Owner
Copy Link

@vblazhkun commented on GitHub (Jul 5, 2020):

What are you connected to in WSL Ubuntu? Vim?

The screenshots are made with Vim, but I have seen a similar issue with multiple apps, including cat, pico, and so on.

@vblazhkun commented on GitHub (Jul 5, 2020): > What are you connected to in WSL Ubuntu? Vim? The screenshots are made with Vim, but I have seen a similar issue with multiple apps, including `cat`, `pico`, and so on.
claunia commented 2026-01-31 01:52:39 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Dec 13, 2020):

@carlos-zamora, @DHowett
Wrapping is taken into account - which seems to be a change in the logic in #4578:

// always apply \r\n for box selection
if (!lineSelection || !GetRowByOffset(iRow).GetCharRow().WasWrapForced())

was replaced by

const bool forcedWrap = GetRowByOffset(iRow).GetCharRow().WasWrapForced();
...
if (!forcedWrap)
{

Regarding the trailing whitespaces - it looks that we remove them in any case (if shift not pressed). Probably we should add a logic that in block selection we preserve them in any case.

I will try to write some short PoC.

@Don-Vito commented on GitHub (Dec 13, 2020): @carlos-zamora, @DHowett Wrapping is taken into account - which seems to be a change in the logic in #4578: ``` // always apply \r\n for box selection if (!lineSelection || !GetRowByOffset(iRow).GetCharRow().WasWrapForced()) ``` was replaced by ``` const bool forcedWrap = GetRowByOffset(iRow).GetCharRow().WasWrapForced(); ... if (!forcedWrap) { ``` Regarding the trailing whitespaces - it looks that we remove them in any case (if shift not pressed). Probably we should add a logic that in block selection we preserve them in any case. I will try to write some short PoC.
claunia commented 2026-01-31 01:52:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 14, 2020):

I'm not sure how I feel about block selection preserving spaces that weren't emitted by the application. Right now, we have an issue where we can't differentiate between spaces emitted by an app and spaces that we use to fill the buffer. I would hate to force block selection to have a bunch of annoying spaces in it unless it was strictly necessary.

(I often use it in a context that could be space-sensitive, like grabbing suffixes off lists of filenames and stuff like that to forward along into another command or an editor.)

How do other terminals do it?

@DHowett commented on GitHub (Dec 14, 2020): I'm not sure how I feel about block selection preserving spaces that weren't emitted by the application. Right now, we have an issue where we can't differentiate between spaces emitted by an app and spaces that we use to fill the buffer. I would hate to force block selection to have a bunch of annoying spaces in it unless it was strictly necessary. (I often use it in a context that could be space-sensitive, like grabbing suffixes off lists of filenames and stuff like that to forward along into another command or an editor.) How do other terminals do it?
claunia commented 2026-01-31 01:52:39 +00:00
Author
Owner
Copy Link

@Don-Vito commented on GitHub (Dec 14, 2020):

I'm not sure how I feel about block selection preserving spaces that weren't emitted by the application. Right now, we have an issue where we can't differentiate between spaces emitted by an app and spaces that we use to fill the buffer. I would hate to force block selection to have a bunch of annoying spaces in it unless it was strictly necessary.

(I often use it in a context that could be space-sensitive, like grabbing suffixes off lists of filenames and stuff like that to forward along into another command or an editor.)

How do other terminals do it?

@DHowett - the alternative today is to remove spaces that were potentially emitted by the application. Not sure which one is better 😊

From what I checked:

  • MinTTY trims
  • ConEmu does not.

I am fine with both approaches actually (both suck equally).

Just let me know which one you prefer and I will adjust the PR (it is still required to treat block selection exclusively).

@Don-Vito commented on GitHub (Dec 14, 2020): > > > I'm not sure how I feel about block selection preserving spaces that weren't emitted by the application. Right now, we have an issue where we can't differentiate between spaces emitted by an app and spaces that we use to fill the buffer. I would hate to force block selection to have a bunch of annoying spaces in it unless it was strictly necessary. > > (I often use it in a context that could be space-sensitive, like grabbing suffixes off lists of filenames and stuff like that to forward along into another command or an editor.) > > How do other terminals do it? @DHowett - the alternative today is to remove spaces that were potentially emitted by the application. Not sure which one is better :blush: From what I checked: * MinTTY trims * ConEmu does not. I am fine with both approaches actually (both suck equally). Just let me know which one you prefer and I will adjust the PR (it is still required to treat block selection exclusively).
claunia commented 2026-01-31 01:52:40 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 28, 2021):

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

Handy links:

@ghost commented on GitHub (Jan 28, 2021): :tada:This issue was addressed in #8579, which has now been successfully released as `Windows Terminal Preview v1.6.10272.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.6.10272.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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 Area-TerminalControl Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
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#9360
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?