[vim/vim] Add a new list-based interface for programming list options in Vim (Issue #13891)
Timothy Madden
Many list options in Vim, like 'path' and 'tags', are difficult to parse correctly from a string, because of the escapes that need to be applied (for the comma ',' and backslash '' characters). Also for the generating a :set command, there is a second level of escapes that needs to be applied... While the complexity can still be dealt with if carefully reading the help text, and experimenting for a while, the process remains very much prone to errors.
Maybe some new interface can be added to access such options as a list value instead of a string, so no parsing or escaping will be needed for vimscript authors.
For example maybe v:tags (and v:path and similar ...) can be a list of tag files, the same as given in the 'tags' option, but already parsed into a list.
Programatically modifying v:tags would also modify the 'tags' option as well, while taking care of properly escape any special characters that should be escaped.
Otherwise the alternative for manually parsing the string value into the list remains to:
- manually split the string value on comma characters ',' that are not preceeded by an odd number of backslashes...
- escape the remaining backslashes by replacing every '\' sequence with ''
Surely every vimscript author out there would like an easier way to deal with this ...
While on this topic, maybe it is possible for fnameescape() function to implement a new flag for escaping a comma ',' character in the file name, for use with :set path command for example.
Maybe I can even make a patch for this if I get enough time to see how the v: dictionary works in Vim source code, and the options themseves ... would that help ? Though I fear the new bytecode engine could make this difficult :(
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
vim-dev ML
On Fri, Jan 19, 2024 at 1:04 PM Timothy Madden ***@***.***>
wrote:
> Many list options in Vim, like 'path' and 'tags', are difficult to parse
> correctly from a string, because of the escapes that need to be applied
> (for the comma ',' and backslash '' characters). Also for the generating a
> :set command, there is a second level of escapes that needs to be
> applied... While the complexity can still be dealt with if carefully
> reading the help text, and experimenting for a while, the process remains
> very much prone to errors.
>
> Maybe some new interface can be added to access such options as a list
> value instead of a string, so no parsing or escaping will be needed for
> vimscript authors.
>
> For example maybe v:tags (and v:path and similar ...) can be a list of tag
> files, the same as given in the 'tags' option, but already parsed into a
> list.
>
> Programatically modifying v:tags would also modify the 'tags' option as
> well, while taking care of properly escape any special characters that
> should be escaped.
>
> Otherwise the alternative for manually parsing the string value into the
> list remains to:
>
>
> Surely every vimscript author out there would like an easier way to deal
> with this ...
>
> While on this topic, maybe it is possible for fnameescape() function to
> implement a new flag for escaping a comma ',' character in the file name,
> for use with :set path command for example.
>
> Maybe I can even make a patch for this if I get enough time to see how the
> v: dictionary works in Vim source code, and the options themseves ... would
> that help ? Though I fear the new bytecode engine could make this difficult
> :(
>
https://groups.google.com/g/vim_dev/c/sCINiwbbs3c/m/mR-jf5HfAgAJ
With this approach, it is possible to export the option value string list
as a List.
Bram didn't see any advantages in this approach compared to the existing
method
of accessing options.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
That patch would only help, if it makes a list or Dict for options with several sub-options. But we would need probably 3 different dicts: for global options, buffer-local and window-local options. Is it really worth it?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
bfrg
@yegappan Why v:vim.opt.shiftwidth and not just v:opt.shiftwidth (or v:option.shiftwidth)? The vim prefix seems redundant.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yegappan Lakshmanan
That patch would only help, if it makes a list or Dict for options with several sub-options.
But we would need probably 3 different dicts: for global options, buffer-local and window-local options. Is it really worth it?
vim-dev ML
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan Why
v:vim.opt.shiftwidthand not justv:opt.shiftwidth(orv:option.shiftwidth)? Thevimprefix seems redundant.
vim-dev ML
On Fri, Jan 19, 2024 at 3:02 PM bfrg ***@***.***> wrote:
> @yegappan <https://github.com/yegappan> Why v:vim.opt.shiftwidth and not
> redundant.
>
>
> I chose v:vim to be consistent with the Python and Lua language interfaces.
Regards,
Yegappan
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.