patch 9.1.1247: fragile setup to get (preferred) keys from key_name_entry
Problem: fragile setup to get (preferred) keys from key_name_entry
(after v9.1.1179)
Solution: refactor the code further, fix a bug with "pref_name" key
entry introduced in v9.1.1180 (Yee Cheng Chin)
The optimization introduced for using bsearch() with key_name_entry
in #16788 was fragile as it required synchronizing a non-obvious index
(e.g. IDX_KEYNAME_SWU) with the array that could be accidentally changed
by any one adding a key to it. Furthermore, the "pref_name" that was
introduced in that change was unnecessary, and in fact introduced a bug,
as we don't always want to use the canonical name.
The bug is triggered when the user triggers auto-complete using a
keycode, such as `:set <Scroll<Tab>`. The bug would end up showing two
copies of `<ScrollWheelUp>` because both entries end up using the
canonical name.
In this change, remove `pref_name`, and simply use a boolean to track
whether an entry is an alt name or not and modify logic to respect that.
Add test to make sure auto-complete works with alt names
closes: #16987
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
diff --git a/src/version.c b/src/version.c
index 271bd82..e0d734c 100644
--- a/src/version.c
+++ b/src/version.c
@@ -705,6 +705,8 @@
static int included_patches[] =
{ /* Add new patch number below this line */
/**/
+ 1247,
+/**/
1246,
/**/
1245,