[vim/vim] vim-9.2.0388 -> 0437 causes 'pp' to be shown on 1st line of file edited with vim (Issue #20140)
David C. Rankin
drankinatty created an issue (vim/vim#20140)Steps to reproduce
- Using konsole (old version from KDE3) to ssh into Archlinux with with vim-9.2.0437,
- starting
vimwith either a new or existing file, "pp"are the first two characters (likely some type of control characters overlayed on the buffer)- downgrading to vim-9.2.0388 resolves the issue.
Expected behaviour
After update from vim-9.2.0388 to vim-9.2.0437, when accessing vim on Archlinux over an ssh connected from an old version of konsole, the first line in each file now shows 'pp' as the first two characters in the file. This did no occur with vim-9.2.0388, a downgrade to that version eliminates the issue.
TERM set to xterm or xterm-256colors makes no difference, using the --clean or -U NONE option to skip the .vimrc makes no difference, but specifying -T /usr/share/terminfo/k/konsole-256color does fix the issue with vim-9.2.0437.
vim should be able to work with various terminals as it did in vim-9.2.0388 without displaying "pp" over the first two characters of the file being edited.
Whatever changed in vim between 9.2.0388 and 9.2.0437 has caused this issue/regression. This appears somewhat similar to '$q q' shows at the first line #2008, though with different characters.
Version of Vim
9.2.0437
Environment
localhost:
openSUSE Tumbleweed
konsole [KDE3]
remote host:
TERM=xterm (or xterm-256colors makes no difference)
bash 5.3.9(1)-release (on both local and remote hosts)
openssh 10.3p1-1
Logs and stack traces
None
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20140)Does this patch possibly fix your issue?
diff --git a/src/term.c b/src/term.c index 37f05ed01..300d503b0 100644 --- a/src/term.c +++ b/src/term.c @@ -5173,7 +5173,7 @@ handle_version_response(int first, int *arg, int argc, char_u *tp) // libvterm sends 0;100;0 // Konsole sends 0;115;0 and works the same way - if ((version == 100 || version == 115) && arg[0] == 0 && arg[2] == 0) + if ((version == 100) && arg[0] == 0 && arg[2] == 0) { // If run from Vim $COLORS is set to the number of // colors the terminal supports. Otherwise assume
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20140)Using konsole (old version from KDE3) to ssh into Archlinux with with vim-9.2.0437,
Isn't that old konsole end-of-life? Can you please share the output of v:termresponse? Does it work in other terminals?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)It's maintained by openSUSE and worked flawlessly up until the change above. What was the compelling need for the change that broke this compatibility. There are also issues with the RaspberryPi 5 showing the same behavior after this change, so it's not just the konsole terminal impacted.
I'm happy to get the output of v:termresponse, but sheepishly how do I get that information? There are some mysteries in vim I've yet to uncover, and v:termresponse is among them :) Checking Vim Docs - term isn't clear on what is needed, or I can't find it there.
(a "Dummy, you press ctrl + v and then ...." would be fine)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20140)echo v:termresponse
Same for your RaspberryPi please. What terminal did you use there?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)The RaspberryPi 5 report is from the Archlinux general mailing list thread:
That doesn't work on my system, which is a rpi 5 that I have built all the packages using
the Archlinux and Alarm PKGBUILDS.I still see the issue
echo $TERM
xterm-256colorvim -T ansi Nothing
pp
The echo v:termresponse provides ^[[>0;115;0c
Which seems to correspond to the - if ((version == 100 || version == 115) && arg[0] == 0 && arg[2] == 0) change.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20140)so does that suggested patch fix it? I don't understand the issue from the Archlinux thread. Not sure what you are trying to say here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)Hold on, give me time to build it, you hit 60 and you don't move quite as fast. Will report back in 15 min.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)Built using Archlinux vim package + github source + patch
Sorry for the wait, build was a challenge, the tests took quite a few minutes extra, especially the tests like:
...
05:31 Executing Test_glvs_default_tar_xz()
10:01 Executing Test_glvs_default_vba_gz()
14:32 Executing Test_glvs_default_vim_bz2()
19:02 Executing Test_glvs_default_vmb()
23:32 Executing Test_glvs_powershell_tar_xz()
...
From test_xxd.vim:
Found errors in Test_xxd_color2():
Run 1, 17:18:27 - 17:18:30 in 2.607827 seconds:
command line..script /home/david/arch/pkg/bld/vim-main/src/vim/src/testdir/runtest.vim[636]..function RunTheTest
...
TEST FAILURE
make[2]: *** [Makefile:58: report] Error 1
make[2]: Leaving directory '/home/david/arch/pkg/bld/vim-main/src/vim/src/testdir'
make[1]: *** [Makefile:2201: scripttests] Error 2
make[1]: Leaving directory '/home/david/arch/pkg/bld/vim-main/src/vim/src'
make: *** [Makefile:39: test] Error 2
==> ERROR: A failure occurred in check().
Aborting...
Grrrr. Build No.2 Skipping checks.
Packages Built/Installed
gvim-9.2.0437-2-x86_64.pkg.tar.zst
vim-9.2.0437-2-x86_64.pkg.tar.zst
vim-debug-9.2.0437-2-x86_64.pkg.tar.zst
vim-runtime-9.2.0437-2-x86_64.pkg.tar.zst
Patch Confirmed
// libvterm sends 0;100;0 // Konsole sends 0;115;0 and works the same way
if ((version == 100) && arg[0] == 0 && arg[2] == 0) { // If run from Vim $COLORS is set to the number of // colors the terminal supports. Otherwise assume
// 256, libvterm supports even more.
if (mch_getenv((char_u *)"COLORS") == NULL)
may_adjust_color_count(256);
// Libvterm can handle SGR mouse reporting.
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
term_props[TPR_DECRQM].tpr_status = TPR_YES;
}Result
It made no difference. I still get the pp at the top of the files on open with vim. Bummer.
What to try next?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20140)Can you tell what version of konsole are you using? I can try compiling that version if the source is available.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)About: says 'Konsole 1.6.6 (Using KDE 3.5.10 "release 283" openSUSE).
Give me a sec and I'll find the URL for the source repositories and edit this comment to update. Thanks.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20140)About: says
'Konsole 1.6.6 (Using KDE 3.5.10 "release 283" openSUSE).Give me a sec and I'll find the URL for the source repositories and edit this comment to update. Thanks.
konsole source
konsoleis part of the kdebase3 package (all of the basic KDE apps were part of kdebase). The source package (.src.rpm) is:kdebase3-3.5.10.1-393.7.src.rpm
All of the KDE3 sources are available updated and building on gcc-16.
If we need to patch the konsole sources, I can get with the openSUSE maintainer (Yasuhiko) and have him apply a patch if it needs patch on that end. But literally, up though this last vim build, it was working perfectly.
Let me know what else you need from me and I'm happy to build/test/etc. on my end.
Additional Problems
This was mentioned on the Arch list that the arrow-keys did not map correctly any longer. I hadn't tried until now, but they no longer do:
When pressing the up-arrow key on the keyboard, "Insert" mode is enabled and an
'A'is inserted. Pressing the down-arrow key invokes insert mode and inserts a'B'. So it seems the term control codes have impacts beyond the"pp"shown on the first line. I'll test the Arch package (their build not mine) and downgrade to 9.2.0388 and test there too.I should mention this was with
vim -T vt320to get around the'pp', testing withvim -T ansi, the arrow keys work fine. So this is likely just a terminal misconfig issue with thevt320builtin.
Can you tell how you built the konsole binary? I'm on Arch Linux, but if thats not possible, I suppose I can try using a Fedora VM... Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)Sure, give me a little bit to search through my notes or contact the maintainer. He has an openSUSE buildservice repository where he does the actual maintenance and building of the packages. kdebase3 is about 10-12 packages into the KDE3 build-order, so there is a bit of setup to get to that point. (as with any desktop, etc..)
I have sent him a post on the openSUSE KDE3 mailing list already letting him know we may need help with patching if it is something that has to be done on the KDE3 end and not something that can be backed out here. There is a bit of a timezone delay is he is located in Japan. Let me see if I can find the link to his buildservice, otherwise it will likely be a few more hours before I have contact with him.
Thank you for your help with this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
susematz
susematz left a comment (vim/vim#20140)The patch as is can't help. The 'pp' is a result of sending DECRQM queries to the terminal. Those queries are only sent when the heuristics say that the terminal will support them. The patch touches one place where it determines "supports" and makes it not claim so on konsole. But there's stuff further down that makes it say "supports". In more context:
if ((version == 100 || version == 115) && arg[0] == 0 && arg[2] == 0)
{
// If run from Vim $COLORS is set to the number of
// colors the terminal supports. Otherwise assume
// 256, libvterm supports even more.
if (mch_getenv((char_u *)"COLORS") == NULL)
may_adjust_color_count(256);
// Libvterm can handle SGR mouse reporting.
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
term_props[TPR_DECRQM].tpr_status = TPR_YES;
}
So, disabling version 115 here makes it not set TPR_DECRQM. Fine, but it also doesn't set TPR_MOUSE anymore, which means the following later code is invoked:
// If no recognized terminal has set mouse behavior, assume xterm.
if (term_props[TPR_MOUSE].tpr_status == TPR_UNKNOWN)
{
// Xterm version 277 supports SGR.
// Xterm version >= 95 supports mouse dragging.
if (version >= 277)
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
else if (version >= 95)
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_XTERM2;
term_props[TPR_DECRQM].tpr_status = TPR_YES;
}
Boom, DECRQM support is claimed again. It seems unhelpful to assume DECRQM just because the status of mouse support is unknown.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
susematz
susematz left a comment (vim/vim#20140)(I will say that as newer konsole does support DECRQM, but that it cannot be differentiated from old konsole by the termresponse numbers (all give '115' :-/) it would seem better to just patch kde3/konsole to accept it as well, instead of wholesale disabling its use in vim for all konsole versions) FWIW, you can check the output of
echo -n -e '\033[?2026$p'
on the terminals of interest. The terminal supports DECRQM if there's no output, and doesn't support it if you see a stale 'p' somewhere.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
David C. Rankin
drankinatty left a comment (vim/vim#20140)Thank you for the further follow up. If you would like me to check another patch on my end, excluding the tests, I've got the patch & build down to just a couple of minutes.
Also, the Archlinux thread where this was discussed vim-9.2.0437 -- inserts 'PP' at start of every new file, downgrading to vim-9.2.0388 resolves the issue, identified the terminal used on the Pi5 that suffers the same problems as being qterminal. It provides the exacts same response to v:termresponse as my KDE3/konsole does (^[[>0;115;0c).
I've downgraded to vim-9.2.0388 for the moment, but I'm happy to patch/build/test if you have something to try that may work around the DECRQM support issue for terminals giving this terminal response.
Again, thank you for looking into this. I've used vim (vi before) for more than two decades, and never really had any issues. I do recall something similar to issue #2008 that many years ago, but other than that vim for managing remote hosts over ssh has been flawless, regardless of which terminal was in front of me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
susematz
susematz left a comment (vim/vim#20140)You might try this:
diff --git a/src/term.c b/src/term.c
index 37f05ed01..18bd86210 100644
--- a/src/term.c
+++ b/src/term.c
@@ -5182,7 +5182,10 @@ handle_version_response(int first, int *arg, int argc, char_u *tp)
may_adjust_color_count(256);
// Libvterm can handle SGR mouse reporting.
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
- term_props[TPR_DECRQM].tpr_status = TPR_YES;
+ // Old konsole doesn't support DECRQM, new ones do but we can't
+ // tell the difference
+ if (version != 115)
+ term_props[TPR_DECRQM].tpr_status = TPR_YES;
}
if (version == 95)
@@ -5228,7 +5231,6 @@ handle_version_response(int first, int *arg, int argc, char_u *tp)
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_SGR;
else if (version >= 95)
term_props[TPR_MOUSE].tpr_status = TPR_MOUSE_XTERM2;
- term_props[TPR_DECRQM].tpr_status = TPR_YES;
}
// Detect terminals that set $TERM to something like
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20140)Does #20161 fix your issue?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.