Unfortunately, only via different positive numbers to remain compatible with the original truthy return values.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1401
These still are limited to numbers and strings (as of Vim 9.1.1401), so List and Dict variables need to be serialized as strings.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1401
We'll need this elsewhere soon, and it also fixes the separate check in ingo#plugin#persistence#Load().
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1401
Since there's both viminfo and session persistence now, both of which can be configured independently, this depends on the name of variable.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1401
This will persist global variables that start with an uppercase letter and contain at least one lowercase letter in a Vim session created by :mksession.
It's not as encompassing as the viminfo persistence, but good enough to be counted.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1401
Extract the duplicated version into a script-local variable and improve the instructions a bit.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.1029
Syntactic sugar that saves the client from checking and defaulting a:list _and_ setting the acceptSingle flag.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.602
Forgot to provide an implementation; for confirm() (and my emulation in ingo#query#Confirm[AsText]()), nothing needs to be done.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.602
Unless with ingo#query#Confirm[AsText](), where an empty list still presents a dialog with |OK| button, here no choices don't make sense, and the query is just confusing:
> Select stuff via [count] or (l)etter: ?
Return -1 / empty string in that case, as if the user aborted.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.602
This allows plugins to assert a compatible ingo-library version and handle a missing dependency gracefully.
There had been user complaints (latest in https://github.com/inkarkat/vim-mark/issues/46) that it's difficult to recognize what needs to be done when the library is missing.
Most users do figure it out eventually (it's documented and the issue templates highlight this as well), but still creates friction. I hope that this is a low-boilerplate solution that's working well for both producer (me) and consumers.
I'd rather have this solved declaratively by package managers, but apparently nothing of that sort has materialized, likely because plugins with dependencies are still rare.
System-info: Ubuntu 20.04.6 LTS, x86_64
Platform-info: Vim 9.1.602
Only split the fragment into collections and other elements if the [ character actually is a special character in the source magicness.
With \V, everything (except the backslash) is taken literally; we must not do translation of collections then.
Closes#3
And there's a general escaping issue with literal insertion; e.g. <C-R> may be interpreted etc.
I could instead paste the expression register, but that would clobber that (and the correct positioning may be tricky).
Leverage the :substitute that is done for the a:isKeepSpace branch, and substitute with a literal NUL character (this can be inserted robustly), then use the same :substitute command to replace it with the literal separator.
With a:isKeepSpace = 1. This might a little bit faster, but it definitely makes the join independent from 'formatoptions' from "j" (remove a comment leader) - "B" and "M" are about spaces around multibyte characters, which doesn't apply to space-constant joining via :join!.
The only use is by my AdvancedSorters.vim, which needs a neutral join (and unjoin) that does not modify the text at all.
It also uses the special join character <Nul>, which can only be inserted literally via <C-V><C-J> in insert mode; now that we're using :substitute we need to explicitly translate that into the ^@ character.
We could use \V...\m, but our own on-demand escaper gives shorter and more developer-friendly regular expressions.
All callers agree that it's a magic pattern, and there's also no documentation that says otherwise.
Ingo Karkat