Glitchy rendering when using kakoune

[lenormf]

Hi,

My main editor is Kakoune, and I can't seem to get it to render properly in a dvtm session. The first "frames" are rendered just fine, but a couple seconds after I've started typing things in, the status bar starts being rendered over the buffer, text randomly disappears, whitespace get inserted into the buffer etc. Using MOD+r always resets the terminal back to what it should be though (everything is displayed properly).

I've tried changing the DVTM_TERM variable to screen/xterm, using ncurses5 over ncurses6, and I've read issues seemingly relevant that have already been created, but nothing I've tried has had any effect on the glitch.

What can I do to pinpoint precisely the cause of this faulty rendering, and how can I work around/fix it ?

Thanks.

[martanne]

Thanks for the report. Did you install the dvtm terminfo description (tic -s dvtm.info, or make install)?

Also what version of the relevant tools (dvtm & kak) did you use? Latest git?

If I find the time, I will try to reproduce the problem.

[lenormf]

Hi,

I'm using dvtm-0.15 on archlinux, the package has been installed with make install and I have the following files in my system:

/usr/bin/dvtm
/usr/bin/dvtm-status
/usr/share/man/man1/dvtm.1.gz
/usr/share/terminfo/d/dvtm
/usr/share/terminfo/d/dvtm-256color

I'm also using ncurses-6.0 (which kakoune uses to do the rendering). I tried issuing tic -s dvtm.info directly, but to no avail.

Thanks.

[greduan]

I can reproduce this, I am using the dvtm package provided by the official Arch Linux packages, not inside abduco.

I just had to open a file and move my cursor down continually and this is the result:

[greduan]

Setting inside kak :set global ui_options ncurses_set_title=false fixes the issue.

Is this something dvtm needs to fix because it's ncurses setting the title or is it because of how kakoune is setting the title? I think it's the former but I dunno.

[mawww]

I think this is more of a Kakoune bug, it sets the title using an escape sequence without making sure the terminal supports it. Not sure how to know if OSC 2 is handled though.

That said, should not dvtm gracefully ignore OSC commands it does not support ?

[martanne]

I think this is more of a Kakoune bug, it sets the title using an escape sequence without making sure the terminal supports it.

dvtm actually does the same, except when running in the linux console which doesn't (or didn't?) support it.

Not sure how to know if OSC 2 is handled though

I too would be interested to know whether there is a simple way to check that.

Back to the issue, dvtm supports the relevant xterm extension to set the window title. I don't have Kakoune at hand, but something like

printf '\033]2;Test - Kakoune\007'

works as expected.

There was a problem that dvtm itself did not properly pass on the given window title (see #32) but this shouldn't matter here?

[mawww]

I think the root of the problem is the use of printf for title handling, mixing buffered and unbufferred output (vt_write uses directly write). The fflush that was added will probably make the problem go away, but why use bufferred output if you dont actually buffer.

[lenormf]

I noticed that rendering corruption didn't happen in kakoune until a certain amount of characters were displayed (usually) around ten. So I went and opened a shell in dvtm (without kakoune), set the title a around twenty times in a row using the last status that was displayed before the artifact appeared in kakoune (printf '\033]2;*scratch* 16:1 [+] insert 1 sel - unnamed0@[29066] - Kakoune\007', executed ~20 times), and surely enough rendering was corrupted (even more badly than when experienced within kakoune if I may say so).

[martanne]

@mawww I don't think that is the case, vt_write is only used for the pseudo tty. However the output stream is shared with curses which depending on the version might do its own buffering or use stdio (see also the NCURSES_NO_SETBUF environment variable). By the way Kakoune seem to do basically the same thing as dvtm.

@lenormf do you still get corruptions with the added flush? This issue might actually be the same as reported in #14 which according to @Link-Satonaka now works.

[lenormf]

Sorry @martanne I hadn't seen your last commit. It seems to have fixed the issue.

[mawww]

@martanne yeah, I did not realize it was ncurses under the hood.

[lenormf]

Since no question was left unanswered, closing this for now.