patch 9.0.0980: the keyboard state response may end up in a shell command
Problem: The keyboard state response may end up in a shell command.
Solution: Only request the keyboard protocol state when the typeahead is
empty, no more commands are following and not exiting. Add the
t_RK termcap entry for this.
diff --git a/runtime/doc/map.txt b/runtime/doc/map.txt
index e0c7106..3f4a371 100644
--- a/runtime/doc/map.txt
+++ b/runtime/doc/map.txt
@@ -1001,10 +1001,15 @@
WARNING: if you map <C-[> you may very well break any key codes that start
with Esc. Make sure it comes AFTER other mappings.
-Vim automatically detects if the modifyOtherKeys mode was enabled when it
-spots an escape sequence that must have been created by it. To see if Vim
-detected such an escape sequence use `:verbose map`, the first line will then
-show "Seen modifyOtherKeys: true" (possibly translated).
+Starting with xterm version 377 Vim can detect the modifyOtherKeys state by
+requesting it. For this the 't_RK' termcap entry is used. When the response
+is found then Vim will know whether modifyOtherKeys level 2 is enabled, and
+handle mappings accordingly.
+
+Before version 377 Vim automatically detects if the modifyOtherKeys mode was
+enabled when it spots an escape sequence that must have been created by it.
+To see if Vim detected such an escape sequence use `:verbose map`, the first
+line will then show "Seen modifyOtherKeys: true" (possibly translated).
This automatic detection depends on receiving an escape code starting with
"<1b>[27;". This is the normal way xterm sends these key codes. However, if
@@ -1016,6 +1021,9 @@
enabled: In Insert mode type CTRL-SHIFT-V CTRL-V, if you get one byte then
modifyOtherKeys is off, if you get <1b>[27;5;118~ then it is on.
+Note that xterm up to version 376 has a bug that makes Shift-Esc send a
+regular Esc code, the Shift modifier is dropped.
+
When the 'esckeys' option is off, then modifyOtherKeys will be disabled in
Insert mode to avoid every key with a modifier causing Insert mode to end.