-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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.
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
Don't copy before pasting in copyOnSelect mode #14635
base: main
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
This changes only the handling of mouse right-clicks, right? I have copy-on-select enabled. Occasionally, I select some text in the terminal and paste it to another program; then copy some other text from a third program and paste that too; then want to paste the text from the terminal again. In that situation, I have been able to switch back to the terminal, where the original text remains selected, and press Ctrl+Insert to copy the same text again. Now, this PR apparently prevents copying with the right mouse button in that scenario -- well, that's okay but please don't hurt my precious Ctrl+Insert. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug:
- ensure copy on select is enabled
- enter mark mode
- make a selection with mark mode
- right-click to copy/paste
expected: selection is copied and pasted immediately
NOTE: similar thing happens when you make a mouse selection, then modify it using quick-edit keys (i.e. shift+right). The selected text is not copied and pasted immediately.
Lemme make sure I get this straight - when you modify the selection with mark mode (with Hmm. Because |
…pyOnSelect-moving-text
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view or the 📜action log for details. Unrecognized words (1)occured Previously acknowledged words that are now absentHirots inthread reingest :arrow_right:To accept ✔️ these unrecognized words as correct and remove the previously acknowledged and now absent words, run the following commands... in a clone of the [email protected]:microsoft/terminal.git repository curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.21/apply.pl' |
perl - 'https://github.com/microsoft/terminal/actions/runs/3940577809/attempts/1' ✏️ Contributor please read thisBy default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
If the listed items are:
See the 🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉 If the flagged items are 🤯 false positivesIf items relate to a ...
|
Sorry, I'm not very experienced in feature implementation workflow. Could someone explain to me which stage this issue is on? |
No worries - this one's just in a bit of a holding pattern. There was an edge case I didn't account for in my original fix. I haven't had time to loop back on this one since. So this isn't fixed in 1.18 yet. Hopefully I can double back on this in July. (If someone else wants to help sort out the edge case above, I'd be happy to have the help) |
Correct! Because if the clipboard contents got updated whenever you move the cursor, you'd copy so many " " to your clipboard! 😆 |
// copied this selection. GH#14464 demonstrates a scenario where the | ||
// buffer contents might have changed since the selection was made, | ||
// and copying here would cause weirdness. | ||
if (_selectionNeedsToBeCopied || !copyOnSelect) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite get why this depends on CopyOnSelect
... When would we ever want to copy text more than once?
I waited for a long time this issue will be fixed and no. New version 1.20 doesn't contain fix for it. I wander why so small number of users confirmed this bug. This feature works ideal on putty, why it can't be fixed on MS Terminal? I believe it's pretty easy to fix. |
I've been working on another project for the last 6 months and have solidly cached this out. I'll probably loop around on all these open PRs after that gets out the door, but I honestly don't remember exactly the interaction that was weird about this fix. I know that it was related to #14635 (review) but I don't recall how the code flowed to cause that anymore. |
In the nutshell the problem is that when copyOnSelect is active it does it twise: onSelect and onPaste (right click). It shouldn't do copy during onPaste operation. In putty, when you select anything, putty shows selection. When you select anything somewhre else and copy it, putty clears it's own selection and after that buffer contains new selection. Which is used for paste on right click. I've read release notes and that's a huge of work. Just hope new version also include fix for this bug. ) |
Don't try to copy if we're in
copyOnSelect
mode, and have already copied this selection.#14464 demonstrates a scenario where the buffer contents might have changed since the selection was made, and copying here would cause weirdness.
Also adds a couple tests for
copyOnSelect
.Closes #14464