GNOME Bugzilla – Bug 787007
Support CSI ? Ps $ p (DECRQM)
Last modified: 2018-03-27 17:51:02 UTC
Recent patches of Vim 8 (starting with 8.0.1009) emit a DECRQM (ESC [ ? 1 2 $ p) on startup to query the status of cursor blinking. VTE doesn't support this and prints U+001B [ ? 1 2 $ p on screen, producing garbage and bug reports. Can you please add support for CSI "?%m$p"? xterm's http://invisible-island.net/xterm/ctlseqs/ctlseqs.html describes DECRQM as CSI ? Ps$ p Request DEC private mode (DECRQM). For VT300 and up, reply is CSI ? Ps; Pm$ y where Ps is the mode number as in DECSET, Pm is the mode value as in the ANSI DECRQM.
How is this DECSET 12 ("Start Blinking Cursor (att610)") mode related to DECSCUSR? For me, in xterm, no matter how I alter DECSET 12 (ESC [ ? 12 h-or-l) and no matter how I set DECSCUSR (ESC [ 0-to-6 SPACE q), I always seem to get back the response "\e[12;2$y" to DECRQM. The querying for the other method, DECSCUSR is not supported by VTE either, but at least it doesn't emit garbage. It's using DCS aka ESC P. See also: https://bugs.kde.org/show_bug.cgi?id=383976 Does vim emit both of these querying strings? Or did it start with one, and upon seeing problems with konsole change to the other one? Apart from the screen corruption that we should address (a part of bug 403130), does it cause any functional problems to vim?
misleading typo: Does vim emit both of these querying strings? Or did it start with one, and upon seeing problems with konsole _changed_ to the other one (I mean the developers changed the code to use the other one only)?
I believe Vim started using DECSCUSR, but that caused problems (garbage output of "$q q" on screen on Vim startup) for Terminal.app users on Macs and it was reverted. There's a longish bug thread at https://github.com/vim/vim/issues/2008 that I skimmed but didn't read in detail. Then Vim 8.0.1009 decided to try DECRQM in https://github.com/vim/vim/commit/4db2554954056f21f2ba4cf4988c652745d7042a. People complained on the list (instead of filing a GitHub issue): https://groups.google.com/forum/#!topic/vim_dev/X7MPNnXz0pE I see that there's already a workaround in 8.0.1016 (https://github.com/vim/vim/commit/f3af54eeb1575618b866aa837e7aca7665aca196) to avoid issuing this query, if the terminal version reported by ESC [ > c looks like VTE, so the urgency of this bug (for me) is suddenly not that important. (Apparently the heuristic fails for VTE 0.38.x from Debian Jessie, but then an upstream VTE fix won't help those users anyway.) I think for vim's purposes, it should be sufficient to ignore this (and, ideally, all unknown escape sequences), especially since VTE doesn't allow programs to toggle cursor blinking via DECSET anyway. AFAIU Vim is making this query only so it can restore the cursor blinking-ness back to what it was before the user launched Vim. (Although, I read bug 403130, and it seemed to me that ignoring or implementing one particular CSI sequence would be easier than making VTE ignore everything, which is why I filed this bug.)
Fixed on master.