Add e_option_is_deprecated_use_str_instead error message (E1575) and apply it to 'completefuzzycollect' and 'wincolor' options.
Setting these deprecated options to a non-empty value now produces an error directing users to the replacement option ('completeopt' and 'winhighlight' respectively). Setting to empty is still allowed for backwards compatibility with scripts that reset these options.
The caller (did_set_string_option) handles restoring the old value when an error is returned, so the callback only needs to return the error.
Update all tests to use 'winhighlight' instead of 'wincolor'.
https://github.com/vim/vim/pull/19768
(14 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
This will be a drastic change in behaviour. Until now, even so other options have been marked as deprecated or obsoleted Vim would not throw an error and still accept it (e.g. there are the 'textauto' and 'textmode' options that are also marked deprecated, so should be set there as well, there are some values of the cryptmethod option that could be marked as well).
I won't merge without confirmation for other maintainers, because this can be quite annoying (possibly for the right reasons). ping @dkearns @yegappan @k-takata for comments please. @zeertzjq how are your handling this over at neovim?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
how are your handling this over at neovim?
IIRC this has changed back and forth for quite a bit. Some related commits:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn, thanks for trying to sort this out.
It would be good to have a path to removal for these deprecated features. However, I think it would be better to do this over several releases and start with a warning that makes a best effort attempt to allow the deprecated option to function in parallel with the replacement as has been done in the past. This can be a bit confusing but I suspect most users don't even notice.
'wincolor' is quite heavily used and having errors generated from plugin use will probably generate a lot of complaints.
With regards to this specific PR, I'm not sure I understand why resetting the values to the default is handled differently? I don't think setting the option to the default value is inherently different.
set wincolor=Black " => error set wincolor= " => functional with no error set wincolor& " => functional with no error
—
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, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
There are only a few deprecated options so far, and we haven't found any compelling reason to force their removal. At most, it will just be a hassle for the maintainers. We'll deal with it when the need arises.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()