Skip to content

fix(clipboard): only use tmux provider if Nvim runs inside tmux#36407

Merged
justinmk merged 1 commit intoneovim:masterfrom
dnnr:push-lxxlspvktuxv
Nov 18, 2025
Merged

fix(clipboard): only use tmux provider if Nvim runs inside tmux#36407
justinmk merged 1 commit intoneovim:masterfrom
dnnr:push-lxxlspvktuxv

Conversation

@dnnr
Copy link
Contributor

@dnnr dnnr commented Oct 31, 2025

This reverts 2495e7e. That past change meant that we would modify the buffer contents of a tmux session if it exists, even if the current Nvim process wasn't running inside of it. Depending on the tmux configuration, this could even affect the clipboard of an actually attached tmux client, since tmux itself uses OSC 52 to forward buffer writes to attached clients.

While autodetection is usually a trade-off and can rarely make everybody happy, this behavior goes counter the principle of least surprise. If really desired, it can be brought back by explicit configuration.

@github-actions github-actions bot added the clipboard clipboard, paste label Oct 31, 2025
@dnnr
Copy link
Contributor Author

dnnr commented Oct 31, 2025

@justinmk I realized I can't do stacked PRs across GitHub forks. So if you decide to first merge #36399 (it sounded like that), I'll will add the update of the documentation here afterwards.

@justinmk
Copy link
Member

could you add a news.txt item (in the news-features section)

@dnnr dnnr changed the title fix(clipboard): Only use tmux provider if Nvim runs in side tmux fix(clipboard): Only use tmux provider if Nvim runs inside tmux Nov 1, 2025
@dnnr dnnr force-pushed the push-lxxlspvktuxv branch 2 times, most recently from 606191c to 3218f9b Compare November 1, 2025 09:16
@dnnr dnnr changed the title fix(clipboard): Only use tmux provider if Nvim runs inside tmux fix(clipboard): only use tmux provider if Nvim runs inside tmux Nov 1, 2025
This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.

While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
@dnnr dnnr force-pushed the push-lxxlspvktuxv branch from 3218f9b to 6e54ced Compare November 1, 2025 09:24
@dnnr
Copy link
Contributor Author

dnnr commented Nov 2, 2025

I assume the failing checks that remain are unrelated to the PR. Let me know if there's anything else I should do.

@justinmk justinmk merged commit d00f680 into neovim:master Nov 18, 2025
59 of 60 checks passed
@neovim neovim deleted a comment from neovim-backports bot Nov 18, 2025
@justinmk
Copy link
Member

Will be included in 0.11.x : #36603

justinmk pushed a commit to justinmk/neovim that referenced this pull request Nov 18, 2025
backport neovim#36407

This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.

While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
justinmk added a commit that referenced this pull request Nov 19, 2025
backport #36407

This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.

While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.

Co-authored-by: Daniel Danner <dnnr@users.noreply.github.com>
yochem pushed a commit to yochem/neovim that referenced this pull request Dec 15, 2025
This reverts 2495e7e. That past change meant that we would modify the
buffer contents of a tmux session if it exists, even if the current Nvim
process wasn't running inside of it. Depending on the tmux
configuration, this could even affect the clipboard of an actually
attached tmux client, since tmux itself uses OSC 52 to forward buffer
writes to attached clients.

While autodetection is usually a trade-off and can rarely make everybody
happy, this behavior goes counter the principle of least surprise. If
really desired, it can be brought back by explicit configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants