The append, prepend, and remove functions now correctly handle empty
option values. When an option is empty (""), we use an empty list
instead of splitting the empty string which would result in [""].
This fixes test failures in OptionScopeTest for operations on empty options.
This allows users to easily retrieve values from option scope:
val x = option { get<Int>("history") }
- Changed option() signature from Unit to generic T return type
- Updated VimApiImpl implementation to return the lambda result
- Added test demonstrating the new return value capability
The implementation always returns a value or throws an exception,
so the return type should be non-nullable to reflect this behavior.
Updated extension functions to remove unnecessary null checks.
- Convert OptionScope from abstract class to interface
- Extract inline functions with reified types as extension functions
- Make getOptionValue() and setOption() public interface methods
- Remove internal modifier layer functions
- Update OptionScopeImpl to implement new interface
- Add documentation recommending extension function usage
- Update test imports to use new extension functions
- append(): adds values to end of comma-separated list (like Vim's +=)
- prepend(): adds values to beginning of list (like Vim's ^=)
- remove(): removes values from list (like Vim's -=)
- All functions prevent duplicate values from being added
- Comprehensive test coverage for all scenarios
Adds a simple toggle() function that flips boolean option values.
Works with both full option names and abbreviations.
Example usage:
toggle("ignorecase") // true → false, false → true
toggle("ic") // works with abbreviations
Adds a concise String.split() extension function within OptionScope that splits
comma-separated option values into lists. This simplifies working with list-type
options like 'virtualedit', 'whichwrap', etc.
Example usage:
val values = get<String>("virtualedit")?.split() ?: emptyList()
// "block,all" → ["block", "all"]
1) ExException is wrapped with the IllegalArgumentException. We cannot use the raw ExException as it's not defined in the API module. So, if any client will have an access only to the API module, they won't be able to handle this kind of the exception.
2) getOption throws IllegalArgumentException if the type classifier is null. I don't know when this might happen, but this looks more like a plugin developer error. Also, this allows to distinguish the wrong option name vs this type of problem
3) In setOption and getOption throw an exception if there is no such option. This clearly explains what is wrong with this call.
Note: there was a question of using exceptions vs some return values, even like `Result`. The decision falls into the using of exceptions as using the wrong arguments in the plugin is a programming error from the user point of view.
This means, if there is a plugin that checks some option that in reality doesn't exist, it's not a fail of the end user and the end user cannot do anything about that.
Also, using the `Result` will force the plugin developer to handle all possible failure branches, what is quite unnecessary when accessing a well-defined option.
This function is not provided by vim and by using it from the plugins we may drop the digraphs created by other plugins.
It'd be better to provide a just remove function. However, let's skip it for now. Also, maybe we should use an approach with the owners
The suspending operations must not be performed under the read or write actions as this will lead to performance issues or freezes.
Also, the current implementation of launching coroutine under the write action is simply incorrect. The coroutine will escape the write action into another thread.
The current representation of Mode with `returnTo` is quite complicated and we're not even sure it'll remain like that.
At the same time, `mode()` function in Vim has quite a reach specification and there is a small chance it'll be changed. With this approach, we use values from Vim, yet in a form of enum.
- We want to be able to execute functions defined on read scope under write lock as well, which means we want to have transaction extend read. However, due to conflicting names for caret scope builders (forEachCaret, withPrimaryCaret etc.) it was necessary to split it into two scopes:
1) Read - contains only functions available under read lock
2) ReadScope - contains both caret scope builders and functions defined on Read
