BREAKING CHANGE: This breaks the OptionSet autocommand, as the `v:` values associated with it (`v:option_new`, `v:option_old`, `v:option_oldlocal` and `v:option_oldglobal`) are now the same type as the option, instead of all option values being converted to strings.
Problem: The style guide states that all switch statements that are not conditional on an enum must have a `default` case, but does not give any explicit guideline for switch statements that are conditional on enums. As a result, a `default` case is added in many enum switch statements, even when the switch statement is exhaustive. This is not ideal because it removes the ability to have compiler errors to easily detect unchanged switch statements when a new possible value for an enum is added.
Solution: Add explicit guidelines for switch statements that are conditional on an enum, clarifying that a `default` case is not necessary if the switch statement is exhaustive. Also refactor pre-existing code with unnecessary `default` cases.
Problem: cmdline-completion for comma-separated options wrong
Solution: Fix command-line expansions for options with filenames with
commas
Fix command-line expansions for options with filenames with commas
Cmdline expansion for option values that take a comma-separated list
of file names is currently not handling file names with commas as the
commas are not escaped. For such options, the commas in file names need
to be escaped (to differentiate from a comma that delimit the list
items). The escaped comma is unescaped in `copy_option_part()` during
option parsing.
Fix as follows:
- Cmdline completion for option values with comma-separated file/folder
names will not start a new match when seeing `\\,` and will instead
consider it as one value.
- File/folder regex matching will strip the `\\` when seeing `\\,` to
make sure it can match the correct files/folders.
- The expanded value will escape `,` with `\\,`, similar to how spaces
are escaped to make sure the option value is correct on the cmdline.
This fix also takes into account the fact that Win32 Vim handles file
name escaping differently. Typing '\,' for a file name results in it
being handled literally but in other platforms '\,' is interpreted as a
simple ',' and commas need to be escaped using '\\,' instead.
Also, make sure this new logic only applies to comma-separated options
like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex
commands like `:edit <Tab>` do not require escaping and will continue to
work.
Also fix up documentation to be clearer. The original docs are slightly
misleading in how it discusses triple slashes for 'tags'.
closes: vim/vim#13303
related: vim/vim#1330154844857fd
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
Problem: Clean up cmdline option completion code
Solution: Fix various minor problems
- Fix manual array size calculations to just use `ARRAY_LENGTH()`.
- Fix unintentional typo in comments due to copy-paste error.
- Fix assert_equal() usages to pass the expected value to first
parameter instead of 2nd one to avoid confusion.
- Fix signed vs unsigned warnings
- Correct misplaced comments about set_op_T and set_prefix_T
and fix a typo in another comment
closes: vim/vim#13249closes: vim/vim#132376d11347260
N/A patch:
vim-patch:9.0.1976: style: space before tab in optionstr.c
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: cmdline completion should consider key option
Solution: Disable cmdline completion for key option, slightly
refactor how P_NO_CMD_EXPAND is handled
Harden crypto 'key' option: turn off cmdline completion, disable set-=
"set-=" can be used maliciously with a crypto key, as it allows an
attacker (who either has access to the computer or a plugin author) to
guess a substring by observing the modified state. Simply turn off
set+=/-=/^= for this option as there is no good reason for them to be
used.
Update docs to make that clear as well.
Also, don't allow cmdline completion for 'key' as it just shows *****
which is not useful and confusing to the user what it means (if the user
accidentally hits enter they will have replaced their key with "*****"
instead).
Move logic to better location, don't use above 32-bit for flags
Move P_NO_CMD_EXPAND to use the unused 0x20 instead of going above
32-bits, as currently the flags parameter is only 32-bits on some
systems. Left a comment to warn that future additions will need to
change how the flags work either by making it 64-bit or split into two
member vars.
Also, move the logic for detecting P_NO_CMD_EXPAND earlier so it's not
up to each handler to decide, and you won't see the temporary "..." that
Vim shows while waiting for completion handler to complete.
closes: vim/vim#132246ee7b521fa
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: Make CI checks more strict
Solution: Add -Wstrict-prototypes -Wmissing-prototypes to CI,
fix uncovered problems
Add -Wstrict-prototypes -Wmissing-prototypes warnings check to CI
Add two new warnings to CI, silence some Perl related build-warnings:
- `strict-prototypes` helps prevent declaring a function with an empty
argument list, e.g. `int func()`. In C++, that's equivalent to `int
func(void)`, but in C, that means a function that can take any number
of arguments which is rarely what we want.
- `missing-prototypes` makes sure we use `static` for file-only internal
functions. Non-static functions should have been declared on a
prototype file.
- Add `no-compound-token-split-by-macro` to the perl cflags, since it
throws out a bunch of perl-related warnings that make the CI log
unnecessary verbose and hard to read. This seems to happen only with
clang 12 and above.
When applying those changes, it already uncovered a few warnings, so fix
up the code as well (fix prototypes, make the code static, remove
shadowed var declaration)
GTK header needs to have #pragma warning suppressiong because GTK2
headers will warn on `-Wstrict-prototypes`, and it's included by gui.h
and so we can't just turn off the warning in a couple files.
closes: vim/vim#13223closes: vim/vim#13226f7f746b167
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: cannot complete option values
Solution: Add completion functions for several options
Add cmdline tab-completion for setting string options
Add tab-completion for setting string options on the cmdline using
`:set=` (along with `:set+=` and `:set-=`).
The existing tab completion for setting options currently only works
when nothing is typed yet, and it only fills in with the existing value,
e.g. when the user does `:set diffopt=<Tab>` it will be completed to
`set diffopt=internal,filler,closeoff` and nothing else. This isn't too
useful as a user usually wants auto-complete to suggest all the possible
values, such as 'iblank', or 'algorithm:patience'.
For set= and set+=, this adds a new optional callback function for each
option that can be invoked when doing completion. This allows for each
option to have control over how completion works. For example, in
'diffopt', it will suggest the default enumeration, but if `algorithm:`
is selected, it will further suggest different algorithm types like
'meyers' and 'patience'. When using set=, the existing option value will
be filled in as the first choice to preserve the existing behavior. When
using set+= this won't happen as it doesn't make sense.
For flag list options (e.g. 'mouse' and 'guioptions'), completion will
take into account existing typed values (and in the case of set+=, the
existing option value) to make sure it doesn't suggest duplicates.
For set-=, there is a new `ExpandSettingSubtract` function which will
handle flag list and comma-separated options smartly, by only suggesting
values that currently exist in the option.
Note that Vim has some existing code that adds special handling for
'filetype', 'syntax', and misc dir options like 'backupdir'. This change
preserves them as they already work, instead of converting to the new
callback API for each option.
closes: vim/vim#13182900894b09a
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
Problem: Cannot use an import in 'foldexpr'.
Solution: Set the script context to where 'foldexpr' was set. (closesvim/vim#9584)
Fix that the script context was not set for all buffers.
e70dd11ef4
Co-authored-by: Bram Moolenaar <Bram@vim.org>
set_option_value() only called did_set_option() for string options,
whereas do_set_option_value() called it for all types.
This change makes set_option_value() call did_set_option() for all types
and thus makes it more consistent with do_set_option_value().
Problem: Problems when setting bin/paste option
Solution: When setting binary/paste, remember that this also affects
depending options, so that :verbose set returns the right
location.
Mention if depending options for 'binary' or 'paste' have been reset
indirectly. Add a test to verify it works.
Also noticed as small bug, that the global option value for expandtab
was not reset when paste option is set, so fix that while at it.
closes: vim/vim#12837closes: vim/vim#12879757593c07a
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: sidescrolloff and scrolloff options work slightly
different than other global-local options
Solution: Make it behave consistent for all global-local options
It was noticed, that sidescrolloff and scrolloff options behave
differently in comparison to other global-local window options like
'listchars'
So make those two behave like other global-local options. Also add some
extra documentation for a few special local-window options.
Add a few tests to make sure all global-local window options behave
similar
closes: vim/vim#12956closes: vim/vim#126434a8eb6e7a9
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Resetting local option to global value is inconsistent.
Solution: Handle "<" specifically for 'scrolloff' and 'sidescrolloff'.
(closesvim/vim#12594)
bf5f189e44
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Option related code uses `char *` for pointer to option value, which is not the best way of representing a type-agnostic pointer.
Solution: Make pointers to option value use `void *` instead.
`option_get_valid_types()` currently uses a comma separator for
multi-type options which does not fit well with the changed error
message for invalid option value type. A slash seperator is much more
suited for its current use-case.
