Some terminals do not properly handle DCS string and/or CSI sequence with intermediate byte.
Therefore, when get the cursor style, garbage string is displayed.
This patch detects such a terminal, checking with termresponse becomes unnecessary.
This patch solves most case of #2008
Tested with following terminals:
(*) has problem with plain vim 8.0.1127.
https://github.com/vim/vim/pull/2126
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
It could be very helpful for the review if you would add your own comment on what will happen to Vim working over SSH of a various combination of platforms and terminals after the proposed patch is merged.
Merging #2126 into master will increase coverage by
0.03%
.
The diff coverage is21.73%
.
@@ Coverage Diff @@ ## master #2126 +/- ## ========================================== + Coverage 73.92% 73.95% +0.03% ========================================== Files 86 90 +4 Lines 131596 131874 +278 Branches 28951 28960 +9 ========================================== + Hits 97280 97530 +250 - Misses 34293 34325 +32 + Partials 23 19 -4
Impacted Files | Coverage Δ | |
---|---|---|
src/main.c | 55.02% <100%> (+0.03%) |
⬆️ |
src/term.c | 50.97% <18.18%> (-0.12%) |
⬇️ |
src/gui_beval.c | 39.87% <0%> (-4.61%) |
⬇️ |
src/window.c | 81.12% <0%> (-0.5%) |
⬇️ |
src/gui_gtk_x11.c | 47.66% <0%> (-0.21%) |
⬇️ |
src/if_xcmdsrv.c | 83.63% <0%> (-0.18%) |
⬇️ |
src/libvterm/src/screen.c | 71.33% <0%> (-0.03%) |
⬇️ |
src/kword_test.c | 66.66% <0%> (ø) |
|
src/message_test.c | 100% <0%> (ø) |
|
src/memfile_test.c | 100% <0%> (ø) |
|
... and 8 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update a8e93d6...c19750f. Read the comment docs.
@brammool Do you mean that we should make new function that do both of may_req_ambiguous_char_width and may_req_xterm_compat_test? Or simply reducing out_flush in may_req_xterm_compat_test? The first one may be bit confusable to read code.
There were some problems with the similar method used to obtain the ambiguous width, but I think they were all solved.
Really? shrug. I'm wondering why this sort of problems is persistent with Vim in comparison with other pieces of OSS software. Seems like this community prefers louder voices. and decisions are made more politically than technically, but people hardly know its politics.
Anyway, while I like the idea, but not-mentioning latency makes me uneasy. Is this trivial? Then just mention it; otherwise, we will need another tweak to make our test suite not-flaky.
—
Make it one function.
updated the patch. Could you check it?
Could you resolve conflicts?
@ttdoda pushed 149 commits.
—
You are receiving this because you are subscribed to this thread.
@ttdoda Hmm, it looks you did something wrong. The history looks broken on the PR page.
I think the following commands fix the problem:
$ git checkout check-dcs-handling
$ git reset --hard 9cfc6cb
$ git push -f ttdoda HEAD # Change "ttdoda" to appropriate remote name if needed.
@k-takata commented on this pull request.
In src/term.c:
> @@ -4511,6 +4555,15 @@ check_termcode( # endif } } + /* Third row is xterm compatibility test */ + else if (row_char == '3') { + if (col != 1) {
Could you move the last {
to the next line? (also for the above line.)
@ttdoda commented on this pull request.
In src/term.c:
> @@ -4511,6 +4555,15 @@ check_termcode( # endif } } + /* Third row is xterm compatibility test */ + else if (row_char == '3') { + if (col != 1) {
updated. thanks!
Oh, 8.0.1303 causes conflict again. @ttdoda, could you resolve it?
@ttdoda Thank you. AppVeyor build failed, but I don't think it is caused by your patch.
I tried your patch on my account, and it successfully passed:
https://ci.appveyor.com/project/k-takata/vim/build/170
This is tricky, but since we keep having problems with various misbehaving terminals I think we should include this. The alternative is to build out the version response checking, which is tedious but perhaps a better long-term solution. We'll see how it goes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.