Arrow keys should move cursor immediately in insert mode, as they do in vim 9.0.
9.1.857
Operating System: Microsoft Windows 10.0.19045 Build 19045
Terminal: xterm-256color
Shell: PowerShell 7.4.6
Old (working) version: VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 28 2022 12:30:17) MS-Windows 32-bit console version
New (problematic) version:
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Nov 11 2024 22:33:33)
MS-Windows 64-bit GUI/console version with OLE support
Comparing :set termcap output between versions reveals different terminal sequences:
OLD:
t_8b=^[|48;2;%lu;%lu;%lum
t_8f=^[|38;2;%lu;%lu;%lum
NEW:
t_8b=^[[48;2;%lu;%lu;%lum
t_8f=^[[38;2;%lu;%lu;%lum
t_8u=^[[58;2;%lu;%lu;%lum
Possible root cause:
In term.c, there's a comment and code that automatically sets these sequences:
// There is no good way to detect that the terminal supports RGB
// colors. Since these termcap entries are non-standard anyway and
// only used when the user sets 'termguicolors' we might as well add
// them. But not when one of them was already set.
This automatic setting of non-standard terminal sequences appears to be putting the terminal in a state that affects arrow key handling.
**Workarounds:**
Running `:!reset` fixes the issue temporarily.
Adding the following to `vimrc` also fixes it permanently, as expected:
```vim
set t_8b=
set t_8f=
set t_8u=
I looked at runtime/doc/todo.txt:
Vim internal, but there should be a terminfo entry for these:
- t_8f set foreground color (R, G, B) in printf() format
- t_8b set background color (R, G, B) in printf() format
- t_8u set underline color (R, G, B) in printf() format
When I use the older format using printf format, like this:
let &t_8f = "\<Esc>|38:2:%lu:%lu:%lum" let &t_8b = "\<Esc>|48:2:%lu:%lu:%lum"
The immediate problem with arrows in insert mode goes away, but it remains when I use the new sequence, which changes | for [. So in this case, it seems that just changing the format alone will not be enough to fix the issue.
The automatic setting of RGB sequences should perhaps be disabled by default, requiring explicit opt-in, as sending these non-standard sequences is causing real usability issues in common terminal configurations. At minimum, there should be a way to disable this behavior without having to explicitly clear the sequences.
The current approach of "sending sequences and hoping for the best" breaks basic editing functionality in scenarios where the terminal doesn't handle these sequences gracefully.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
SSH into Windows machine using PowerShell
What exactly does that mean and what terminal are you using? You seem to have an issue with your terminal. Unfortunately, there is no standard way for some of those terminal extensions (like the true color mode). So I'd suggest to configure the escape sequences for terminalguicolors instead of relying on the default.
Comparing :set termcap output between versions reveals different terminal sequences:
Can you please bisect the offending commit
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Win32 console version of Vim uses the ^[| style escape sequences. So, I think
In
term.c, there's a comment and code that automatically sets these sequences:
this should be disabled if MSWIN is defined.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()