[Feature Request] Improved support for FZF and tmux

[stevenwalton]

I have issue #217 opened where I'm discussing issues with support over ssh and tmux, but a main part of my goal is to get chafa working in fzf under tmux so that I can easily search and preview images on remote servers. There is also a related issue in the wezterm project trying imgcat, which I believe shares some similar issues.

There are some issues with fzf especially around the window size but there is added complexity once we use tmux.

I am using this function for the samples and will note if I change

# We determine later if we're using `bat` or `batcat` because there's 2 hard problems in CS
# e.g. export_fzf_defaults batcat
function export_fzf_defaults() {
    # Be sure to use --view-size instead of --size and set --exact-size on so that we
    # only downscale images and at worst make them fit the preview window size
    if (_exists fzf && (_exists bat || _exists batcat) && _exists chafa )
    then
        export FZF_DEFAULT_OPTS='--ansi --preview
        "if file --mime-type {} | grep -qF image;
        then
            chafa --passthrough none -f sixels --exact-size on --view-size $(( ${FZF_PREVIEW_COLUMNS}-50 ))x$(( ${FZF_PREVIEW_LINES}-50 )) {};
        elif file --mime-type {} | grep -aF -e text -e json;
        then
            bat --color=always --theme=Dracula --style=numbers,grid --line-range :500 {};
        fi"'
    elif (_exists fzf && (_exists bat || _exists batcat) )
    then
        export FZF_DEFAULT_OPTS='--ansi --preview "$1 --color=always --theme=Dracula --style=numbers,grid --line-range :500 {};"'
    fi
}

The chafa line is all that matters and you will only need fzf and chafa to reproduce the error. bat is included for transparency. (This can most certainly be cleaned up)

Here is an example of things working over ssh correctly.

Now when we use tmux (I have no idea why IMG_9635.jpg is the default here while IMG_9630.jpg is what's found by the other 2. This is a fzf issue. Noted since it is easy to miss).

Modifying command for --passthrough tmux

An interesting note is in our function we have the part $(( ${FZF_PREVIEW_<HW>} - 50 )) instead of directly calling ${FZF_PREVIEW_COLUMNS} directly. I found that when calling directly we tend to get an output like this

(We scrolled up because many images appear like the second screenshot where nothing is visible)

There's clearly some differentiation in how fzf counts vschafa. I have not dug into this and our offset is a dirty patch to try to focus on one problem at a time.

If we instead use a larger offset such as 100 then chafa reports an error:

chafa: View size must be specified as [width]x[height], [width]x or x[height], e.g. 80x25, 80x 

(the message is cut off)

I'm fairly that the values are negative here.

[AnonymouX47]

As for --passthrough=tmux not working, I'm willing to put all I've got on the RegEx at

https://github.com/junegunn/fzf/blob/855f90727af7827d9934b7fa00ea5ed51f5e4e81/src/terminal.go#L77

being the culprit, particularly the portion \x1bPtmux;\x1b\x1b.*?[^\x1b]\x1b\\. This attempts to match a complete Tmux passthrough sequence but it actually doesn't for any with an embedded ESC (\x1b) (i.e within the passthrough payload).

See the RegEx used in the function here.

It seems the sequence chafa is emitting doesn't match the RegEx. Hence, fzf doesn't recognize it as an image sequence and doesn't pass it through it's TUI layer (which would most likely otherwise scrub out control characters from text). That's why you have something resembling the emitted sequence within the preview pane.

[hpjansson]

It seems the sequence chafa is emitting doesn't match the RegEx. Hence, fzf doesn't recognize it as an image sequence and doesn't pass it through it's TUI layer (which would most likely otherwise scrub out control characters from text). That's why you have something resembling the emitted sequence within the preview pane.

@AnonymouX47 Great catch. Could be worth filing an issue with fzf, I guess?

@stevewalton What happens if you leave passthrough off and pass $FZF_PREVIEW_COLUMNS unmodified, but make the terminal window small? I feel like we're still just up against tmux' hard image size limit (note: size of the transferred sixels, not the input file - so you can still preview big files, but only in a small window).

[stevenwalton]

Sorry idk how I missed the comments here. We're still facing some fzf + tmux issues, though much more minor now. Here's a gif of changing screen size with the normal sizing options. It does not dynamically update. (ssh + fzf + tmux)

Start Big

Start Small

I'm pretty sure we'll need to take this up with fzf though. I set FZF_DEFAULT_OPTS='--ansi --preview "if file --mime-type {} | grep -qF image; then echo ${FZF_PREVIEW_COLUMNS} x ${FZF_PREVIEW_LINES} {}; fi"' and as you might guess, the numbers do not change.

I was also playing with some other options in fzf and realized there's fzf --tmux which will by default make a tmux popup window. Unfortunately this does not result in any rendering

Works fine with my other options though. Maybe there's an error message I can get chafa to spit out?

FWIW things are perfectly fine when I use the shell integration (in zsh pressing ), but that's not causing a tmux popup. So at least we're doing good on that front.

[hpjansson]

Sorry idk how I missed the comments here. We're still facing some fzf + tmux issues, though much more minor now. Here's a gif of changing screen size with the normal sizing options. It does not dynamically update. (ssh + fzf + tmux)

Dynamic updates would need to be handled by fzf. Chafa draws the image at the requested size, as long as it's passed along correctly by the configuration/script wrapper.

I'm pretty sure we'll need to take this up with fzf though. I set FZF_DEFAULT_OPTS='--ansi --preview "if file --mime-type {} | grep -qF image; then echo ${FZF_PREVIEW_COLUMNS} x ${FZF_PREVIEW_LINES} {}; fi"' and as you might guess, the numbers do not change.

Yes, if fzf is redrawing the view correctly, but not recalculating the image size for the previewer, that sounds like an fzf bug.

I was also playing with some other options in fzf and realized there's fzf --tmux which will by default make a tmux popup window. Unfortunately this does not result in any rendering

Works fine with my other options though. Maybe there's an error message I can get chafa to spit out?

This is likely related to how fzf creates the new terminal window. Unfortunately, Chafa doesn't have any reporting that could help, but you could try various things, like substituting -f symbols to see if symbols mode is working. If it is, it's likely related to the new terminal window being mis-detected (maybe it's inheriting some bogus env vars?).

FWIW things are perfectly fine when I use the shell integration (in zsh pressing ), but that's not causing a tmux popup. So at least we're doing good on that front.

Awesome!