You're seeing an apparent limitation in the native Windows version of Vim (vim.exe
) due to the specifics of Windows' VT (Virtual Terminal) support - and the limitation applies irrespective of whether you launch vim.exe
stand-alone, from a conhost.exe
window (regular console window), or from Windows Terminal:
The Job-to-Vim terminal escape sequence you mention (as documented here) is quietly ignored.
Technically, due to starting with <ESC>]
, the escape sequence at hand is of type OSC (Operating System Command), specifically with parameter 51
; on the Windows API side - the VT (Virtual Terminal) support in console windows - at least some of those OSC sequences are supported, as implied by the statements in Console Virtual Terminal Sequences:
By contrast, the Job-to-Vim escape sequence does work on Unix-like platforms, including when running Vim from inside WSL on Windows (/usr/bin/vim
).
The following describes how to emit such an escape sequence from PowerShell in principle, but for the reasons stated, it won't solve your problem in Windows Terminal / Windows console windows.
In PowerShell (Core) 7.3+, from a Unix environment,
printf '\033]51;["drop", "README.md"]\07'
should work as-is.
(In v7.2-, due to a long-standing bug, you'll have to escape the "
chars. as \"
- see this answer).
The PowerShell-native v7+ equivalent - which works on all platforms - is (see the conceptual about_Special_Characters help topic):
Write-Host -NoNewLine "`e]51;[`"drop`", `"README.md`"]`a"
(In Windows PowerShell, escape sequence `e
to produce an ESC char. isn't supported; use $([char] 27)
instead.)
Note that "`e]51;[`"drop`", `"README.md`"]`a"
alone, using PowerShell's implicit output mechanism, would implicitly print a newline after the string value, hence the use of Write-Host -NoNewLine
(alternatively, use [Console]::Write(...)
)