Fish Shell breaks Kitty image previews with ranger

[purxiz]

Please tell us which fish version you are using by executing the following:
fish, version 3.1.1

Please tell us which operating system and terminal you are using. The output of uname -a and echo $TERM may be helpful in this regard although other commands might be relevant in your specific situation.

Ubuntu 20.04 with Kitty Terminal

Please tell us if you tried fish without third-party customizations by executing this command and whether it affected the behavior you are reporting:

sh -c 'env HOME=$(mktemp -d) fish'

Occurs on a fresh install of fish in a VM, with the only 3rd party program being ranger's rc.conf to enable image previews. This bug is documented on the ranger page here, but I believe it to be an error(?) in fish shell, rather than with ranger:

ranger/ranger#1919

Steps to reproduce are install ranger, enable image previews and set image_preview_method=kitty.

Image previews work properly in BASH, but in FISH, only a portion of the image is shown. The image is not resized to fit the pane, and the ranger panes are no longer drawn while the portion of the image is being previewed.
I have tried downgrading to 3.1.0-1.2 (the only other version available in apt for Ubuntu 20.04), and the issue persists, though slightly differently. The picture is still rendered incorrectly, with only a portion of it being drawn, but only the text in the ranger panes disappear. The outlines remain.

I also tried with version 3.1.2, issue still persists.

Here is a picture of the issue:

The expected behavior is that I can still see the bounding boxes on ranger, as well as the contents, and the image is resized to fit into the right pane. Here is an image just before the image preview finishes loading. Once it is displayed, the terminal looks like above.

These images were produced on fish 3.1.2.

Here is the expected behavior:

[ammgws]

I get this from time to time as well, didn't think it might be due to fish.

[purxiz]

@ammgws for me it's working with bash, if you get a chance, it would be useful to test on fish 3.0.2, as the other thread claims that it's not broken in that version.

[zanchey]

Marking this as a bug though I think it needs more characterisation; I can't get kitty to run on my machine for whatever reason.

[purxiz]

@zanchey I'm happy to provide whatever test output or additional info is relevant/needed. I updated the post with some images to describe the problem, but I really don't know much if anything about how shell programming works, so I'm not sure about a solution at all.

[faho]

I've managed to get the previews to work, but I can't see a difference between fish and bash here. Both resize the image in what seems to be an aspect-ratio preserving manner?

The obvious thing to check are the environment variables (e.g. is there a difference in $PATH, so that this executes a different thing in the background). It is also possible fish turns something on in kitty or prints something at some point.

[purxiz]

@faho Did you set preview_images_method = kitty in your ranger.conf? For me, w3m (the default) works with both, but kitty does not work with fish while bash does, path's identical, empty kitty.conf and empty fish config.

[ammgws]

I'm getting the same behaviour in bash as well, however I'm running bash from fish so it might be due to something in my environment.

[faho]

Okay, I spoke too soon.

It's only really visible with a large image and I was testing with small ones. The weird part if I launch fish from bash, exit it immediately and then start ranger from bash it reproduces. So there is some state in kitty that gets triggered from fish, and it's not terminal modes (which would be the obvious candidate, but 1. the only difference is ixon and 2. changing it doesn't change anything).

Tbh this seems quite likely to be an issue in kitty at this point.

[callahad]

I can confirm that Fish 3.0.2 works as expected, and 3.1.0 fails.

There were only 2,210 commits between the two releases, so we should be able to bisect the regression in about a dozen builds.

...not that I'm volunteering. But not that I'm not volunteering, either.

[callahad]

Git bisect reports that 8031fa3 is the first bad commit.

I manually re-verified that its parent 3d25ce1 works as expected.

[callahad]

(I do not have the experience or time to effectively pursue this further, but hopefully the bisect is helpful. I'm more than happy to test patches.)

[ammgws]

Probably not a coincidence that the code changed in that commit had to do with termsize.

@ridiculousfish does anything look suss here?