Screen scrolls up one line when entering view mode under Ghostty terminal emulator

[exoton]

Describe the bug
Screen scrolls up one line when entering view mode under Ghostty terminal emulator.

To Reproduce
Steps to reproduce the behavior:

1. Run clifm under Ghostty.
2. Enter view command.
3. See the error.

Expected behavior
The screen should look like this:

Screenshots
Instead it looks like this:

Desktop

• OS: NixOS
• Terminal: Ghostty
• CliFM version: 1.23
• Installation source: Nix

[leo-arch]

Does this happen only with Ghostty? Have you enabled image previews? In that case, what preview method are you using? If running out of the box, it should be sixel, since Ghostty reports supporting it. However, sixel support in Ghostty is not optimal: images are not cleared after display. Maybe related to your issue, maybe not.

Is this happening also with regular TAB completion?

[leo-arch]

Spotted the issue. Here is it:

Ghostty does support sixel in some experimental and even undocumented way, but it's only partially supported, generating the display issues you see on the screen.

Now, why, despite the fact that clifm knows that this terminal does not support sixel ($CLIFM_IMG_SUPPORT is indeed set to ansi - find it out running env) is it displaying sixel images?

Here's why: the clifmimg script (~/.config/clifm/clifmimg) uses chafa to generate ANSI previews. But, for compatibility with older chafa versions, it uses this command: chafa --symbols=all ... But, in newer versions, when sixel and other image displaying methods where added, they added the -f flag to specify the required method. If not, and this is our case, it tries to autodetect what the terminal actually support (for some reason, it detects sixel support on Ghostty).

Briefly stated, the command we use to fire up image previews isn't working as expected. As a workaround, edit ~/.config/clifm/clifmimg and replace the line 248, which reads:

chafa) chafa --symbols=all -s "${C}x${L}" "$1" ;;

by this one:

chafa) chafa -f symbols -s "${C}x${L}" "$1" ;;

to force chafa to use ANSI art instead of sixels.

Drawback, only ANSI images will be displayed, but since sixel support is at most half of its way, this is the only thing this terminal can offer right now.

As a side note, the ueberzug method does not work either.

---

A fun/weird/buggy fact. On Ghostty, run this command:

chafa -f sixels image.jpg

Nothing, no image is displayed. Now run this other command:

chafa image.jpg

A sixel image! Why on earth is this happening?

[leo-arch]

Also, as a proof of concept. Go to your images directory, and run (not in clifm, but in you regular shell):

ls | fzf --preview 'chafa {}'

You'll see the same scrolling issue. Conclusion: this is not our issue.

[exoton]

Thank you for the detailed response. I'll look into it later.

[leo-arch]

According to this issue Ghostty will definitely not support sixels. The question still remains: how to explain the behavior exposed above? I've taken a look at the source code, and there's not a single word about sixels. Weird.

[leo-arch]

Found out that if you reduce the size of the image displayed by chafa you can make the scroll thing go away:

chafa) chafa --symbols=all -s "${C}x$((L - 2))" "$1" ;;

However, images are still not cleared, which makes it rather useless.

[exoton]

A fun/weird/buggy fact. On Ghostty, run this command:

chafa -f sixels image.jpg
Nothing, no image is displayed. Now run this other command:

chafa image.jpg
A sixel image! Why on earth is this happening?

Is it possible that in this case

chafa image.jpg

is equivalent to

chafa -f kitty image.jpg

[exoton]

I've found chafa options that fix the issue:

--margin-bottom num
    When terminal size is detected, reserve at least this many rows at the bottom as a safety margin. Can be used to prevent images from scrolling out. Defaults to 1.

...

ls | fzf --preview 'chafa --clear --margin-bottom 2 {}'

I've just noticed that this is practically what you did.

[leo-arch]

You're right. I completely overlooked the fact that Ghostty supports the Kitty graphics protocol.

Regarding the chafa options, this is what I've found:

1. Using --view-size instead of -s fixes the scrolling issue (without the need to manually modify the geometry)

# ~/.config/clifm/clifmimg:148
chafa) chafa --view-size "${C}x${L}" "$1" ;;

2. The --clear option doesn't seem to be working: images are not cleared. Found this unresolved discussion about this very problem in the Ghostty repo itself.

[leo-arch]

After taking a look at this script, I've found out how to solve the clearing issue. Edit ~/.config/clifm/clifmimg and set the $method variable (line 112) to kitty (this won't be necessary since the next commit though: I've added Ghostty as a kitty supporting terminal to the source code itself).

However, we still have some displaying issues with big images. Fixed this by just reducing the width.

# ~/.config/clifm/clifmimg:232
kitty)
     kitty icat --loop=0 --place "$((FZF_PREVIEW_COLUMNS - 2))x$((FZF_PREVIEW_LINES - 1))@${X}x${Y}" \
     --clear --transfer-mode=memory --unicode-placeholder --stdin=no --align=left "$1"
     ;;

[leo-arch]

this won't be necessary since the next commit though.

Done. Now kitty is automatically detected if running on Ghostty (no need to set the $method variable in clifmimg anymore). But, you still need to manually reduce the image width passed to the kitty icat command, as done in the previous comment.

EDIT: With the latest commit, both issues are definitely fixed. The new code for kitty images is this:

# ~/.config/clifm/clifmimg:232
kitty)
     kitty icat --loop=0 --place "${C}x$((L - 1))@${X}x${Y}" \
     --clear --transfer-mode=memory --unicode-placeholder --stdin=no --align=left "$1"
     ;;

[exoton]

Does it mean that I need to install kitty just for image preview?

[leo-arch]

I was thinking about the same thing. Definitely not good, so maybe I'll revert back the commit making Ghostty terminals automatically use the kitty method.

On the other side, without the kitty method, i.e. using chafa, we still have the clearing issue.

EDIT: We need to replicate the behavior of the kitty command above but without kitty.

[exoton]

Can we use a wrapper around chafa that clears the screen before calling chafa?

[leo-arch]

Gave this try, but it doesn't work. This is the script I've tried:

~/.chafa.sh

#!/bin/sh

clear
chafa -f kitty --clear --view-size "${1}x${2}" "$3"

invoked from ~/.config/clifm/clifmimg, line 148, as follows:

    chafa) ~/chafa.sh "$C" "$L" "$1" ;;

Nothing, the image isn't cleared. I've even tried replacing clear by printf "\033c" and printf "\x1b[H\x1b[2J\x1b[3J" to no avail: the image is still there, on top of whatever text was there before.

BTW. whatever clear command we use, the text is removed as expected, but not the image, which remains on top.

As a side note, the clear command can be used directly in the case statement in the clifmimg script, without the need of invoking a new script, which just adds the extra overhead of spawning a new subshell:

chafa) clear; chafa -f kitty --clear --view-size "${C}x${L}" "$1" ;;

[leo-arch]

Seems we've gone back to this unresolved issue.

[leo-arch]

I've even tried the fzf-preview script provided by fzf itself, but no luck: images accumulate one on top of the other.

[leo-arch]

Tried with two other terminals with support for the Kitty graphics protocol: Konsole and Wezterm.

1. On Wezterm, images are not displayed at all.
2. On Konsole, we get the same clearing issue: images are kept on top no matter what.

The command I'm using is this:

ls *.png *.jpg | fzf --preview 'chafa -f kitty --clear {}'

It's not clear what conclusions can be drawn from this, but at least we know that Ghostty is not alone in this.

---

I thought about taking a look at how other programs generate image previews via the Kitty protocol. Ranger can do this, so let's see how it goes. Tried three terminals with kitty support. The results:

1. Kitty terminal: Smooth.
2. Wezterm: No preview.
3. Konsole: No preview.

It seems it's hard to make the kitty protocol work outside the kitty terminal itself.

[exoton]

I wonder if it is caused by graphics being at a different address. May be we are not clearing the buffer with the image.

[leo-arch]

The only way I know that actually works is with kitten icat --clear (I've used it before). But, again, you need kitty installed for this to work, so that we're not going anywhere either way.

[leo-arch]

Hey @exoton, since this is not a clifm issue, I converted it into a discussion.