patch 9.1.1180: short-description

patch 9.1.1180: short-description

Problem:  The meaning of <Tab> depends on unspecified behavior
          (after 9.1.1179).
Solution: Return TAB in case bsearch() finds K_TAB.  Rename alt_name to
          pref_name as that's closer to it meaning (zeertzjq).

The man page of bsearch() says:

    The bsearch() function returns a pointer to a matching member of the
    array, or NULL if no match is found.  If there are multiple elements
    that match the key, the element returned is unspecified.

So it's possible that bsearch() finds K_TAB instead of TAB when trying
to get the key code for <Tab>. Actually, it can happen when adding a
single key to end of the table:

closes: #16821

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
diff --git a/src/misc2.c b/src/misc2.c
index 151745ca2..90f108a24 100644
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -1141,7 +1141,8 @@ static struct key_name_entry
     {TRUE, K_XRIGHT, STRING_INIT("xRight"), NULL},
     {TRUE, K_XUP, STRING_INIT("xUp"), NULL},
     {TRUE, K_ZEND, STRING_INIT("zEnd"), NULL},
-    {TRUE, K_ZHOME, STRING_INIT("zHome"), NULL}
+    {TRUE, K_ZHOME, STRING_INIT("zHome"), NULL},
+    {TRUE, -1, STRING_INIT("zzDummyKey"), NULL}
     // NOTE: When adding a long name update MAX_KEY_NAME_LEN.
 };
 #undef STRING_INIT

Meanwhile IDX_KEYNAME_TAB doesn't do anything, as TAB and K_TAB have the
same name.

Signed-off-by: Christian Brabandt <cb@256bit.org>