Instead of keeping `P_ALLOCED` and `P_DEF_ALLOCED` flags to check if an
option value is allocated, always allocate option values to simplify the
logic.
Ref: #25672
Problem: We use `void *` for option default values, which is confusing and can cause problems with type-correctness. It also doesn't accomodate for multitype options. On top of that, it also leads to default boolean option values not behaving correctly on big endian systems.
Solution: Use `OptVal` for option default values.
BREAKING CHANGE:
- `:set {option}<` removes the local value for all global-local options instead of just string global-local options.
- `:setlocal {option}<` copies the global value to the local value for number and boolean global-local options instead of removing the local value.
Problem: Currently, the `immutable` property of options can be applied for options that are hidden and options whose value simply can't be changed. Which is problematic when attempting to convert an option like `'maxcombine'` into an immutable option, because trying to `:set` an immutable option currently gives an error, which is only desired behavior for hidden options, not options that are actually immutable.
Solution: Separate the `immutable` property into two distinct `hidden` and `immutable` properties. Change all options with the `immutable` property to use the `hidden` property instead. Also add `p_mco` as an `immutable` option, as its value cannot be changed, and the underlying variable is not used anywhere.
Problem: Setting some options changes curswant unnecessarily.
Solution: Add a P_HLONLY flag that prevents changing curswant.
(zeertzjq)
closes: vim/vim#14044fcaed6a70f
Problem:
APIs get wrong boolean option default values on big-endian platforms.
Solution:
Use a union for def_val.
Cannot use OptVal or OptValData yet as it needs to have the same types
as option variables.
Problem:
`findoption()` searches through the options[] table linearly for option
names, even though hashy can be used to generate a compile-time hash
table for it.
Solution:
Use hashy to generate a compile time hash table for finding options.
This also allows handling option aliases, so we don't need separate
options[] table entries for things like 'viminfo'.
Problem: We have `P_(BOOL|NUM|STRING)` macros to represent an option's type, which is redundant because `OptValType` can already do that. The current implementation of option type flags is also too limited to allow adding multitype options in the future.
Solution: Remove `P_(BOOL|NUM|STRING)` and replace it with a new `type_flags` attribute in `vimoption_T`. Also do some groundwork for adding multitype options in the future.
Side-effects: Attempting to set an invalid keycode option (e.g. `set t_foo=123`) no longer gives an error.
Add a macro to indicate the option count so that we can iterate through the options[] table more clearly. This also removes the need for having an option with NULL fullname at the end of `options[]`.
Problem: Many places in the code use `findoption()` to access an option using its name, even if the option index is available. This is very slow because it requires looping through the options array over and over.
Solution: Use option index instead of name wherever possible. Also introduce an `OptIndex` enum which contains the index for every option as enum constants, this eliminates the need to pass static option names as strings.
Problem:
Not all Lua code is checked by stylua. Automating code-style is an
important mechanism for reducing time spent on accidental
(non-essential) complexity.
Solution:
- Enable lintlua for `src/` directory.
followup to 517f0cc634
Problem: We use the `p_force_on` and `p_force_off` variables to check if a variable is immutable and what its default value is. This is not only hacky and unintuitive, but also is limited to only boolean options.
Solution: Replace `p_force_on` and `p_force_off` with an `immutable` property for options, which indicates if an option is immutable. Immutable options cannot be changed from their default value.
Ref: #25672.
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: 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
* docs(options): take ownership of options.txt
- `src/nvim/options.lua` is now the source of truth
- generate runtime/lua/vim/_meta/options.lua
* fixup! zeer comments
* fixup! zeer comments (2)
* fixup! re-enable luacheck
* fixup! regen
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.
Problem: Handling new value of an option has a long "else if" chain.
Solution: Use a function pointer. (Yegappan Lakshmanan, closesvim/vim#12015)
af93691b53
Problem:
Build is not reproducible, because generated source files (.c/.h/) are not
deterministic, mostly because Lua pairs() is unordered by design (for security).
https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671https://www.lua.org/manual/5.1/manual.html#pdf-next
> The order in which the indices are enumerated is not specified [...]
>
>> The hardening of the VM deliberately randomizes string hashes. This in
>> turn randomizes the iteration order of tables with string keys.
Solution:
- Update the code generation scripts to be deterministic.
- That is only a partial solution: the exported function
(funcs_metadata.generated.h) and ui event
(ui_events_metadata.generated.h) metadata have some mpack'ed
tables, which are not serialized deterministically.
- As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can
inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0)
that preserves table order.
- Longer-term we should change the mpack'ed data structure so it no
longer uses tables keyed by strings.
Closes#20124
Co-Authored-By: dundargoc <gocdundar@gmail.com>
Co-Authored-By: Arnout Engelen <arnout@bzzt.net>
Problem: Cannot assign a lambda to an option that takes a function.
Solution: Automatically convert the lambda to a string. (Yegappan
Lakshmanan, closesvim/vim#9286)
6409553b6e
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
With #20374 tabline option is marked with 'statuslines' redraw flag.
But 'statuslines' doesn't redraw tabline. As a result, tabline doesn't
get redrawn when tabline option is set and statuslines get unnecessarily redrawn.
This patch fixes the issue by adding a new redraw flag P_RTABL to redraw
tabline.
This was used in the past with assumption that curwin/curbuf
is "special" but this has not been true since basically forever
at this point.
Reduce NOT_VALID/CLEAR panic in options.lua . These should not
be set if an effect of the option is causing something
which by itself invokes redraw_later().
Problem: Using expressions in a modeline is unsafe.
Solution: Disallow using expressions in a modeline, unless the
'modelineexpr' option is set. Update help, add more tests.
110289e781
Problem: Cannot set 'dictionary' to a path.
Solution: Allow for slash and backslash. Add a test (partly by Daisuke
Suzuki, closesvim/vim#1279, closesvim/vim#1284)
7554da4033
