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
This can be disabled via a:options.isAllowDigraphs = 0. The query functions for register, mark, substitute confirm, history recall, and confirmed filter disallow that as it's not needed.
By moving the Callback invocation above the recall stack manipulation, and evaluating its return value (accounting for all the different variable types) instead of just passing it through.
For a List, we need a maximum of 9, and for a direct recall, we just need the count'th one. I don't want to introduce two separate APIs for the list and the indexed get; I think a combination that just asks for a List slice is a good compromise. Clients can completely ignore this and return the full List. Other clients may have to iterate over a source and for those the opportunity to stop early when enough is produced is valuable, though.
The direct recall mistakenly uses the index (a:count - 1), whereas the list uses the 1-based choice. So the last history gets a recalled identity of "1 when selected from the list but one of "0 when recalled directly. Despite identical contents, the number mismatch causes an unexpected push to the top.
Correct the former to consistently use 1-based counts.
The recalled number and the first recalled item become identical, and then the check finds no differences, so the current recall is not put back on top. This breaks an A-B-B cycling when the recall history becomes B-A-B; the second B is not put on top to B-B-A, and (second) B will repeat indefinitely.
Adapt the position of recalled things (e.g. on "3 from 3 to 1), then on a repeat ("3 again), the recall number is different (though the contents are not), and the cycling continues.
The named slot likely has the greatest stability and will likely be used soon, so to avoid recording duplicates in the recall history, this should be used.
Most clients likely want a deduplicated history (just like Vim's built-in histories for commands, searches, etc.). However, my PrevInsertComplete.vim can employ duplicate entries with the cycling effect to repeatedly insert A-A-B by pushing (via named recalls) A into two different named registers (and then recalling via "3).
Ingo Karkat