[vim/vim] fix GVim does not lose selection ownership and does not use VisualNOS when it should (PR #20046)
依云
fixes #19914.
I don't really know what condition is better to put here, but since the patch introduced this issue (#19659) is about clipboard provider, I think this is good enough?
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/20046
Commit Summary
- b2c49d2 fix GVim does not lose selection ownership and does not use VisualNOS when it should
File Changes
(1 file)
- M src/drawline.c (2)
Patch Links:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20046)@shaneharper any comment?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Shane Harper
shaneharper left a comment (vim/vim#20046)- The updated condition disables VisualNOS entirely when using the clipboard provider, but I believe these features aren't mutually exclusive - a user could run gvim with the clipboard provider and still expect VisualNOS to be used.
- the documentation for hl-VisualNOS should be updated; VisualNOS can be used with Wayland (not just when using X11).
- " && defined(FEAT_X11)" could be removed from line 1467.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
依云
@lilydjwg pushed 1 commit.
- 3a72edd update doc, remove FEAT_X11 guard
—
View it on GitHub or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20046)The updated condition disables VisualNOS entirely when using the clipboard provider, but I believe these features aren't mutually exclusive - a user could run gvim with the clipboard provider and still expect VisualNOS to be used.
There is no interface for a clipboard provider to declare that it is no longer the owner.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Shane Harper
shaneharper left a comment (vim/vim#20046)The updated condition disables VisualNOS entirely when using the clipboard provider, but I believe these features aren't mutually exclusive - a user could run gvim with the clipboard provider and still expect VisualNOS to be used.
There is no interface for a clipboard provider to declare that it is no longer the owner.
You're right.
I can't imagine any problems introduced by the condition you used (clipmethod != CLIPMETHOD_PROVIDER).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Shane Harper
shaneharper left a comment (vim/vim#20046)Before writing patch 9.2.0158 I had considered an alternative fix: ensuring that clip_star.owned and/or clip_plus.owned are set to TRUE when the clipboard-provider feature is in use. With that in place, the existing condition in win_line() could have been left unchanged — no extra guard needed. I wish I'd explored that approach further; I believe the resulting code would have been neater, and #19914 would likely have been avoided.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.