Add the 'pumopacity' option (0-100, default 100) to control popup completion menu transparency, similar to the existing 'opacity' property for popup windows.
When pumopacity < 100, the background content shows through the popup menu. The implementation saves the background screen content before drawing the pum, then blends pum colors with the saved background using hl_pum_blend_attr() for space cells and hl_blend_attr() for text cells.
https://github.com/vim/vim/pull/19739
(11 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
The options for pum (popup menu) have increased quite a bit ('pumborder', 'pumheight', 'pummaxwidth', 'pumwidth'). With 'pumopacity', that makes five.
It might be time to consider introducing a new 'pumopt' option to consolidate these, similar to 'diffopt', 'completeopt', and 'statuslineopt'.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Thanks, I tend to agree on a consolidated pumopt setting.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Should we treat 'pumborder', 'pumheight', 'pummaxwidth', and 'pumwidth' as deprecated?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Yes, I think we should mark it as "deprecated" in the documentation and remove it in the next or the one after that major release.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I'm currently implementing pumopt. Please note that the addition of this option will change how pumwidth, pumheight, etc. have been handled.
When only width is specified in pumopt, height (i.e., pumheight) will be reset to its default value. In other words, to specify both pumwidth and pumheight using pumopt, you need to specify both at once:
set pumopt=width:20,height:10
I looked into the history of diffopt, statuslineopt, and completeopt, and found that all of them were introduced as single consolidated options from the start — none of them were introduced to consolidate pre-existing individual options like we are doing now.
So I plan to add a new error like e_option_is_deprecated and change pumwidth, pumheight, pumborder, pummaxwidth, and pumopacity to read-only. The values can still be read (e.g., echo &pumheight), but setting them will produce an error directing users to use pumopt instead.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I perfer to add new error e_option_is_deprecated . Anyone thought?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Anyway I should not include the error e_option_is_deprecated in this pull-request. Should be separated.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I'm currently out and haven't checked the existing source codes and documentation, but wouldn't the current behavior, where pumwidth and pumheight are interacting with each other, be considered a bug? Conversely, I don't understand the reason for doing so.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I looked into how other comma-separated string options behave when only some values are specified:
diffopt: set diffopt=icase resets all flags/context/algorithm to hardcoded defaults first, then only applies icase. filler, internal, etc. are all cleared.completeopt: set completeopt=menu starts with new_flags = 0 and only sets the specified flags. All other flags are cleared.statuslineopt: set statuslineopt=fixedheight initializes fixedheight=FALSE, maxheight=1 (defaults) first, then applies specified keys.renderoptions: If type:directx is omitted, DirectX is disabled entirely.All of these options reset unspecified values to their defaults. This is the standard behavior for comma-separated options in Vim. So set pumopt=width:3 resetting height to its default (0) is consistent with this pattern, not a bug.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
As an aside, Vim currently has some precedent for deprecated options:
completefuzzycollect — marked as DEPRECATED in the docs. Setting it still succeeds, but cfc_flags is not referenced anywhere, so it has no effect at all.wincolor — marked as DEPRECATED in the docs. Setting it internally redirects to winhighlight via update_wincolor(), so it still works but is redundant.Neither of these produce an error when set. In a separate PR, I plan to introduce e_option_is_deprecated and make setting these (and the old pum options) produce an error, so that deprecated options are handled consistently.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I'm sorry, I completely misunderstood.
(I mistakenly thought you were saying that setting pumwidth clears the value of pumheight.)
When only width is specified in pumopt, height (i.e., pumheight) will be reset to its default value. In other words, to specify both pumwidth and pumheight using pumopt, you need to specify both at once:
set pumopt=width:20,height:10
Regarding the above, yes, that's how it's designed.
If you want to set it individually, you would use +=.
set pumopt+=width:3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
To clarify: this PR only adds the pumopacity option. It does not deprecate pumwidth, pumheight, pumborder, or pummaxwidth, and does not introduce pumopt.
The pumopt consolidation and the e_option_is_deprecated error will be done in a separate PR.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
To clarify: this PR adds pumopacity and pumopt, but does not deprecate the existing individual options (pumwidth, pumheight, pumborder, pummaxwidth). They continue to work as before. The deprecation with e_option_is_deprecated will be handled in a separate PR.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Looking back at it, it doesn't make sense to add pumopacity when we decided to add pumopt.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Removed pumopacity
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 14 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I found a behavior difference between pumheight and pumopt height:. The pum position differs — with pumopt=height:N the pum appears 2 lines lower than with set pumheight=N. Let me investigate and fix this before merging.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Thanks. I am including this now. However I noticed the two new dump files are exactly the same. Shouldn't there be a difference?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
included as of 317351c
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()