Add ability to not automatically copy whitespace-only selections #15871

Open
opened 2026-01-31 04:50:58 +00:00 by claunia · 5 comments
Owner

Originally created by @wilbur4321 on GitHub (Nov 12, 2021).

Automatic copy to clipboard and clicking in the terminal window combine to overwrite the contents of the clipboard with some whitespace or a single character, far too often/easily.

I find myself, and I imagine others do as well, accidentally selecting something when clicking into the terminal to give it focus, which then wipes out whatever I had in the clipboard that I was about to paste. Window's clipboard history allows retrieval, at least, but it's a few extra steps.

I can think of couple possible solutions off-hand:

  • When both copyOnSelect is enabled, it would be wonderful to have an option to NOT automatically copy whitespace-only and/or single-character selections.
  • Just automatically, quietly, don't do white-space only or single-character selections within a short period of the terminal window gaining focus. Getting the exact conditions for this could be tricky; something like "within the first 0.5 seconds of gaining focus, and only the first click/drag (or touch), ignore it".

Either of these options (or something similar) should be basically invisible to the user, functioning to protect mistakes with minimal to no impact upon intentional actions, much like palm rejection in apps/systems does.

Originally created by @wilbur4321 on GitHub (Nov 12, 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! --> Automatic copy to clipboard and clicking in the terminal window combine to overwrite the contents of the clipboard with some whitespace or a single character, far too often/easily. I find myself, and I imagine others do as well, accidentally selecting something when clicking into the terminal to give it focus, which then wipes out whatever I had in the clipboard that I was about to paste. Window's clipboard history allows retrieval, at least, but it's a few extra steps. <!-- 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). --> I can think of couple possible solutions off-hand: - When both `copyOnSelect` is enabled, it would be wonderful to have an option to NOT automatically copy whitespace-only and/or single-character selections. - Just automatically, quietly, don't do white-space only or single-character selections within a short period of the terminal window gaining focus. Getting the exact conditions for this could be tricky; something like "within the first 0.5 seconds of gaining focus, and only the first click/drag (or touch), ignore it". <!-- A clear and concise description of what you want to happen. --> Either of these options (or something similar) should be basically invisible to the user, functioning to protect mistakes with minimal to no impact upon intentional actions, much like palm rejection in apps/systems does.
claunia added the Help WantedIssue-TaskProduct-TerminalArea-TerminalControl labels 2026-01-31 04:50:59 +00:00
Author
Owner

@DHowett commented on GitHub (Nov 12, 2021):

Hmm!

Here's my hot take: what if we just never (without a config option) copy whitespace-only text in copyOnSelect mode? I wonder how many people would complain. Probably Vince would notice...

@DHowett commented on GitHub (Nov 12, 2021): Hmm! Here's my hot take: what if we just _never_ (without a config option) copy whitespace-only text in `copyOnSelect` mode? I wonder how many people would complain. Probably Vince would notice...
Author
Owner

@wilbur4321 commented on GitHub (Nov 12, 2021):

That would be a huge gain in and of itself! Wouldn't cover the situation where one clicks on an area that contains text to get focus, but that is something we ought to be able to train ourselves to not do, TBH. My only concern would be for people that do copy whitespace only to match indentations.

There exists an option to auto-trim whitespace on rectangular selections (but it does leave new lines). Adding the equivalent for non-rectangular selections and then changing both to not auto-copy whitespace-only selections might be perfect, too!

Still, though, I think the idea of automatic rejection of a selection that occurs right after focus and has a very tiny drag period could be done pretty easy, wouldn't require having (and documenting and testing) another configuration option, and would Just Work (tm).

@wilbur4321 commented on GitHub (Nov 12, 2021): That would be a huge gain in and of itself! Wouldn't cover the situation where one clicks on an area that contains text to get focus, but that is something we ought to be able to train ourselves to not do, TBH. My only concern would be for people that do copy whitespace only to match indentations. There exists an option to auto-trim whitespace on rectangular selections (but it does leave new lines). Adding the equivalent for non-rectangular selections and then changing both to not auto-copy whitespace-only selections might be perfect, too! Still, though, I think the idea of automatic rejection of a selection that occurs right after focus and has a very tiny drag period could be done pretty easy, wouldn't require having (and documenting and testing) another configuration option, and would Just Work (tm).
Author
Owner

@sredna commented on GitHub (Dec 9, 2021):

I think the idea of automatic rejection of a selection that occurs right after focus

This leaves out one scenario, scrolling by dragging with touch input. It is not nearly as annoying as the focus thing but if you have ever used the terminal on a small screen touch-only device you would know my pain.

@sredna commented on GitHub (Dec 9, 2021): > I think the idea of automatic rejection of a selection that occurs right after focus This leaves out one scenario, scrolling by dragging with touch input. It is not nearly as annoying as the focus thing but if you have ever used the terminal on a small screen touch-only device you would know my pain.
Author
Owner

@pabohoney1 commented on GitHub (May 22, 2024):

This would be fantastic to implement, I have to re-copy many times a day in my workflow because of empty copies when switching between windows.

@pabohoney1 commented on GitHub (May 22, 2024): This would be fantastic to implement, I have to re-copy many times a day in my workflow because of empty copies when switching between windows.
Author
Owner

@erbanku commented on GitHub (Oct 10, 2025):

Any update? This is very annoying, especially since it scrolls through many pages unintentionally and is hard to stop.

@erbanku commented on GitHub (Oct 10, 2025): Any update? This is very annoying, especially since it scrolls through many pages unintentionally and is hard to stop.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15871