Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

wordDelimiters not working inside tmux with [shift]+[left mouse click] #9382

Closed
Kristijan opened this issue Mar 4, 2021 · 5 comments · Fixed by #9403
Closed

wordDelimiters not working inside tmux with [shift]+[left mouse click] #9382

Kristijan opened this issue Mar 4, 2021 · 5 comments · Fixed by #9403
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v1.8

Comments

@Kristijan
Copy link

Environment

Windows build number: 10.0.18363.1379
Windows Terminal version (if applicable): 1.6.10571.0

Any other software?
Ubuntu using WSL 1
tmux 3.2-rc2 (set-option -g mouse on)

I run tmux from another Linux server, so the flow is:
Windows Terminal --> Ubuntu WSL 1 --> SSH to remote host --> tmux

Steps to reproduce

I updated from Microsoft WindowsTerminal 1.5.10271.0 to 1.6.10571.0 and have been using the following configuration for wordDelimiters "wordDelimiters": " ()\"':,;<>~!@#$%^&*|+=[]{}~?│".

With 1.5.10271.0, the wordDelimiters were honored in both my Ubuntu WSL 1 zsh shell (double click left mouse button), and inside tmux (shift + double click left mouse button).

With 1.6.10571.0, the wordDelimiters are honored in my Ubuntu WSL 1 zsh shell (double click left mouse button), but not inside tmux (shift + double click left mouse button). Holding the shift key and double clicking to select text from within tmux only partially selects text (such as entire words), and doesn't honor the wordDelimiters confugration.

Expected behavior

The expected behavior is that selecting text from within tmux with (shift+double click left mouse button) works as it did in Microsoft WindowsTerminal 1.5.10271.0.

Actual behavior

The actual behavior is that selecting text from within tmux with (shift+double click left mouse button) only partially selects text with Microsoft WindowsTerminal 1.6.10571.0.
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Mar 4, 2021
@DHowett
Copy link
Member

DHowett commented Mar 4, 2021

@Don-Vito may be a regression from the shift click selection endpoint change #8611 :(

@Don-Vito
Copy link
Contributor

Don-Vito commented Mar 4, 2021

@DHowett - I will try to take a look in the next few days.

@Don-Vito
Copy link
Contributor

Don-Vito commented Mar 5, 2021 •
edited
Loading

So the problem is following: currently shift+click selects a single cell. When the second tap occurs, instead of applying the double-click logic we simply extend the selection, resulting in partial selection.

To address this I suggest to extend selection only with shift+single-click. I will issue a PR with more details.

@Don-Vito Don-Vito mentioned this issue Mar 5, 2021
Closed
6 tasks
@ghost ghost added In-PR This issue has a related PR and removed In-PR This issue has a related PR labels Mar 5, 2021
@Don-Vito Don-Vito mentioned this issue Mar 7, 2021
Merged
6 tasks
@ghost ghost added the In-PR This issue has a related PR label Mar 7, 2021
@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. labels Mar 8, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Mar 8, 2021
@zadjii-msft zadjii-msft added this to the Terminal v1.8 milestone Mar 8, 2021
@zadjii-msft zadjii-msft linked a pull request Mar 8, 2021 that will close this issue
Fix selection logic with shift on multi-click #9403
Merged
6 tasks
@ghost ghost closed this as completed in #9403 Mar 8, 2021
@ghost ghost removed the In-PR This issue has a related PR label Mar 8, 2021
ghost pushed a commit that referenced this issue Mar 8, 2021
@Don-Vito
Fix selection logic with shift on multi-click (#9403)
83f2a3b 
## PR Checklist
* [x] Closes #9382
* [x] CLA signed. 
* [ ] Tests added/passed
* [ ] Documentation updated. 
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. 

## Detailed Description of the Pull Request / Additional comments
The selection with shift is quite broken in 1.6.

It started with #8611 that introduces cell selection on `shift+click`.
This change resulted in the following defect:
`shift+double-click`, `shift+triple-click` select only parts  of the word.
The reason for this is that the first `shift+click` establishes the selection,
while the consequent clicks simply extend it to the relevant boundary
(aka word / line boundary)

However, the logic was broken even before #8611.
For instance, `shift+triple-click` had exactly the same handicap:
`shift+double-click` was establishing the selection and the
third click was simply extending it to the line boundary.

This PR addresses the both defects in the following manner:
upon multi-click that starts new selection we establish
a new selection on every consequent click using appropriate mode
(cell/word/line) rather than trying to extend one.
For this purpose we remember the position that started the selection.
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Mar 8, 2021
DHowett pushed a commit that referenced this issue Mar 15, 2021
@Don-Vito @DHowett
Fix selection logic with shift on multi-click (#9403)
763dab5 
## PR Checklist
* [x] Closes #9382
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.

## Detailed Description of the Pull Request / Additional comments
The selection with shift is quite broken in 1.6.

It started with #8611 that introduces cell selection on `shift+click`.
This change resulted in the following defect:
`shift+double-click`, `shift+triple-click` select only parts  of the word.
The reason for this is that the first `shift+click` establishes the selection,
while the consequent clicks simply extend it to the relevant boundary
(aka word / line boundary)

However, the logic was broken even before #8611.
For instance, `shift+triple-click` had exactly the same handicap:
`shift+double-click` was establishing the selection and the
third click was simply extending it to the line boundary.

This PR addresses the both defects in the following manner:
upon multi-click that starts new selection we establish
a new selection on every consequent click using appropriate mode
(cell/word/line) rather than trying to extend one.
For this purpose we remember the position that started the selection.

(cherry picked from commit 83f2a3b)
DHowett pushed a commit that referenced this issue Mar 15, 2021
@Don-Vito @DHowett
Fix selection logic with shift on multi-click (#9403)
03b373f 
## PR Checklist
* [x] Closes #9382
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.

## Detailed Description of the Pull Request / Additional comments
The selection with shift is quite broken in 1.6.

It started with #8611 that introduces cell selection on `shift+click`.
This change resulted in the following defect:
`shift+double-click`, `shift+triple-click` select only parts  of the word.
The reason for this is that the first `shift+click` establishes the selection,
while the consequent clicks simply extend it to the relevant boundary
(aka word / line boundary)

However, the logic was broken even before #8611.
For instance, `shift+triple-click` had exactly the same handicap:
`shift+double-click` was establishing the selection and the
third click was simply extending it to the line boundary.

This PR addresses the both defects in the following manner:
upon multi-click that starts new selection we establish
a new selection on every consequent click using appropriate mode
(cell/word/line) rather than trying to extend one.
For this purpose we remember the position that started the selection.

(cherry picked from commit 83f2a3b)
@DHowett DHowett removed the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Apr 8, 2021
@ghost
Copy link

ghost commented Apr 14, 2021

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

Handy links:

@ghost
Copy link

ghost commented Apr 14, 2021

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

Handy links:

@github-actions github-actions bot mentioned this issue May 9, 2024
Open
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal v1.8
Development

Successfully merging a pull request may close this issue.

Fix selection logic with shift on multi-click Don-Vito/terminal
4 participants
@DHowett @Kristijan @Don-Vito @zadjii-msft