Doesn't clear screen correctly in Ghostty

[fearlessgeekmedia]

Describe the bug I'm a beta tester for Ghostty. When going to other directories using the Ghostty terminal, out of the box, it doesn't clear the screen first before printing out the contents of the new directory.

Additional context For the user, this can be worked around by setting the TERM environment variable to xterm-kitty.

[leo-arch]

Hi @fearlessgeekmedia, and thanks for reporting.

This issue is most likely due to the fact that clifm refuses to use capabilities not reported by the terminal emulator (via TERM), which is why it works fine by just setting TERM to "xterm".

Too bad I cannot test this myself. However, what value is Ghostty using for TERM by default?

[fearlessgeekmedia]

xterm-ghostty

On Tue, Sep 17, 2024 at 9:41 AM leo-arch @.***> wrote:

Hi @fearlessgeekmedia https://github.com/fearlessgeekmedia, and thanks for reporting.

This issue is most likely due to the fact that clifm refuses to use attributes and features not reported by the terminal emulator (via TERM), which is why it works fine by just setting TERM to "xterm".

Too bad I cannot test this myself. However, what value is Ghostty using for TERM by default?

— Reply to this email directly, view it on GitHub https://github.com/leo-arch/clifm/issues/308#issuecomment-2356286823, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3HGA5UMOODARFW7SAL562LZXBERZAVCNFSM6AAAAABOLXR5YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJWGI4DMOBSGM . You are receiving this because you were mentioned.Message ID: @.***>

[leo-arch]

The thing is that xterm-ghostty is not in the terminfo database, so that applications running on top of the terminal do not know what capabilities it provides. I guess I can add xterm-ghostty to clifm's internal database using the same capabilities set than xterm-256color, but this is far from ideal.

EDIT: Normally, new terminal emulators provide an extra package (say ghostty-terminfo) with the required terminfo information, until this info is provided by the terminfo database itself (usually via the ncurses package).

[fearlessgeekmedia]

Ah ok.

On Tue, Sep 17, 2024 at 9:50 AM leo-arch @.***> wrote:

The thing is that xterm-ghostty is not in the terminfo database, so that applications running on top of the terminal do not know what capabilities it provides. I guess I can add xterm-ghostty to clifm's internal database using the same capabilities set than xterm-256color, but this is far from ideal.

— Reply to this email directly, view it on GitHub https://github.com/leo-arch/clifm/issues/308#issuecomment-2356316546, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3HGA5UIMCCK2JTJKUYTJGTZXBFWHAVCNFSM6AAAAABOLXR5YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJWGMYTMNJUGY . You are receiving this because you were mentioned.Message ID: @.***>

[leo-arch]

I think it makes sense that it's not in the terminfo database.

Of course. I didn't expect it to be otherwise. This is why, while in beta, it's better to let applications know the terminal capabilities set, at least partially, by faking TERM to to be a know value (say xterm-256color), provided Ghostty is 100% xterm-compatible.

I'll keep Ghostty in mind (looks promising) until it is released for *nix.

[mattrobenolt]

👋

Hi there @leo-arch, I am not a CLIFM user, but I am a Ghostty contributor. So my 2 cents here.

While we are private beta, we do have our terminfo in a user's local terminfo database under the names xterm-ghostty, ghostty, and Ghostty, though we currently advertise by default as xterm-ghostty.

ghostty terminfo

``` $ infocmp -x # Reconstructed via infocmp from file: /Applications/Ghostty.app/Contents/Resources/terminfo/78/xterm-ghostty xterm-ghostty|ghostty|Ghostty, am, bce, ccc, hs, km, mc5i, mir, msgr, npc, xenl, AX, Su, Tc, XT, fullkbd, colors#256, cols#80, it#8, lines#24, pairs#32767, acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, fsl=^G, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS, initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, invis=\E[8m, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~, kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~, kri=\E[1;2A, oc=\E]104\007, op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m, rmul=\E[24m, rs1=\E]\E\\\Ec, sc=\E7, setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m, setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m, sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd, BD=\E[?2004l, BE=\E[?2004h, Clmg=\E[s, Cmg=\E[%i%p1%d;%p2%ds, Dsmg=\E[?69l, E3=\E[3J, Enmg=\E[?69h, Ms=\E]52;%p1%s;%p2%s\007, PE=\E[201~, PS=\E[200~, RV=\E[>c, Se=\E[2 q, Setulc=\E[58\:2\:\:%p1%{65536}%/%d\:%p1%{256}%/%{255}%&%d\:%p1%{255}%&%d%;m, Smulx=\E[4\:%p1%dm, Ss=\E[%p1%d q, Sync=\E[?2026%?%p1%{1}%-%tl%eh%;, XM=\E[?1006;1000%?%p1%{1}%=%th%el%;, XR=\E[>0q, fd=\E[?1004l, fe=\E[?1004h, kDC3=\E[3;3~, kDC4=\E[3;4~, kDC5=\E[3;5~, kDC6=\E[3;6~, kDC7=\E[3;7~, kDN=\E[1;2B, kDN3=\E[1;3B, kDN4=\E[1;4B, kDN5=\E[1;5B, kDN6=\E[1;6B, kDN7=\E[1;7B, kEND3=\E[1;3F, kEND4=\E[1;4F, kEND5=\E[1;5F, kEND6=\E[1;6F, kEND7=\E[1;7F, kHOM3=\E[1;3H, kHOM4=\E[1;4H, kHOM5=\E[1;5H, kHOM6=\E[1;6H, kHOM7=\E[1;7H, kIC3=\E[2;3~, kIC4=\E[2;4~, kIC5=\E[2;5~, kIC6=\E[2;6~, kIC7=\E[2;7~, kLFT3=\E[1;3D, kLFT4=\E[1;4D, kLFT5=\E[1;5D, kLFT6=\E[1;6D, kLFT7=\E[1;7D, kNXT3=\E[6;3~, kNXT4=\E[6;4~, kNXT5=\E[6;5~, kNXT6=\E[6;6~, kNXT7=\E[6;7~, kPRV3=\E[5;3~, kPRV4=\E[5;4~, kPRV5=\E[5;5~, kPRV6=\E[5;6~, kPRV7=\E[5;7~, kRIT3=\E[1;3C, kRIT4=\E[1;4C, kRIT5=\E[1;5C, kRIT6=\E[1;6C, kRIT7=\E[1;7C, kUP=\E[1;2A, kUP3=\E[1;3A, kUP4=\E[1;4A, kUP5=\E[1;5A, kUP6=\E[1;6A, kUP7=\E[1;7A, kxIN=\E[I, kxOUT=\E[O, rmxx=\E[29m, rv=\E\\[[0-9]+;[0-9]+;[0-9]+c, setrgbb=\E[48\:2\:%p1%d\:%p2%d\:%p3%dm, setrgbf=\E[38\:2\:%p1%d\:%p2%d\:%p3%dm, smxx=\E[9m, xm=\E[<%i%p3%d;%p1%d;%p2%d;%?%p4%tM%em%;, xr=\EP>\\|[ -~]+a\E\\, ```

I think this should fall in line with how other terminals are supported through your term_info.h in here, but I could be gravely mistaken.

The issue I see failing is specifically here: https://github.com/leo-arch/clifm/blob/master/src/checks.c#L177-L187

One thing to note is that Ghostty also fully supports the Kitty graphics protocol, so I think that hardcoded check for xterm-kitty as well would likely be applicable for Ghostty, granted, I don't exactly know what all KITTY_TERM enables, nor do I personally know the CLIFM featureset, but Ghostty aims to support a lot of Kitty features.

I think personally downgrading Ghostty to xterm-256color is woefully inaccurate and would drop a lot of features of what I'd consider a "modern terminal".

Is there an aversion to adding xterm-ghostty|ghostty|Ghostty into your term_info.h based on our terminfo file? It seems there's a very wide array of support in there currently for things like Alacritty, Kitty, Wezterm, etc.

What would be required to get us in there without needing to fake our TERM for users that want to use CLIFM?

[leo-arch]

Hi @mattrobenolt.

What would be required to get us in there without needing to fake our TERM for users that want to use CLIFM?

I suggested to fake TERM only while in beta, because I have no access to your terminfo. Now, if you can send me a copy of your terminfo, I'll gladly generate a new entry for ghostty in our term_info.h database (until the data is provided by terminfo itself).

[mattrobenolt]

Now, if you can send me a copy of your terminfo

It's in my first comment in the collapsed section so it didn't take up your whole screen. :)

Right now too, I'd suggest adding xterm-ghostty into the KITTY_TERM flag check as well, or maybe roll that bit flag into the terms_t struct as well, given many other terminals support a lot of the kitty protocols.

(There's also methods for discovering these features without string matching on TERM.)

[leo-arch]

It's in my first comment in the collapsed section so it didn't take up your whole screen. :)

I was talking about the file itself, not the infocmp output: with he file I can do this automatically, instead of checking the values manually.

As to the kitty image protocol, it's not that easy: we use this via FZF, but since this latter doesn't support the kitty protocol itself (I mean, plain escape codes), we need to use the icat kitten, which I assume is specific to kitty. In this scenario, it doesn't make sense to add ghostty there.

[mattrobenolt]

Re the KITTY_TERM flag, it seems there's a few hardcoded assumptions throughout that kitty is the only terminal emulator to support images, which is objectively incorrect.

I'm not going to suggest making these changes just for us, but for context, there's a spec for how to generically query kitty protocol support: https://sw.kovidgoyal.net/kitty/graphics-protocol/#querying-support-and-available-transmission-mediums

But many terminals beyond kitty support their protocol (similar to sixel), which is intended to be a generic spec.

[mattrobenolt]

As to the kitty image protocol, it's not that easy: we use this via FZF, but since this latter doesn't support the kitty protocol itself (I mean, plain escape codes), we need to use the icat kitten, which I assume is specific to kitty. In this scenario, it doesn't make sense to add ghostty there.

Ah, fair. Yeah, depending explicitly on the icat kitten definitely would require kitty to be installed at minimum even though kitty icat would work within ghostty and others. (There are other generic tools for this, but that's quite tangential.)

I've attached everything in Ghostty's terminfo.

terminfo.zip

[leo-arch]

There are other generic tools for this

I can take a look at this. Can you suggest a few?

Thanks for the file. I'll add it to my local database and generate a new entry for it in our term_info.h.

[mattrobenolt]

https://github.com/hzeller/timg is the one I'm familiar with, and I want to say the most common outside of the icat kitten. But I've also heard of https://github.com/atanunq/viu

Kitty documents lots of tools here tho: https://sw.kovidgoyal.net/kitty/integrations/#image-and-document-viewers

[leo-arch]

Done (https://github.com/leo-arch/clifm/commit/b5004dcc02143d252bf4e521970f290d6dfd47f5). It should work fine now. Please let me know if it works as expected.

[fearlessgeekmedia]

Yep! Just built it on my system and it runs well! Thank you!

[leo-arch]

You're welcome. Closing. Please consider reopening this issue if anything comes up.