Image previews are off when lf is called from inside a neovim terminal

[noib3]

Not really sure if this is lf's or neovim's fault, but ueberzug image previews seem to be off when lf is launched from inside a neovim :terminal. The following are two screenshots of the same image preview, in the first one lf is launched from alacritty and in the second one from neovim:

Can anyone reproduce this?

[slavistan]

Can reproduce.

My wild guess would be that nvim's reduction of the effective terminal area is not communicated to lf, which then communicates the "incorrect" preview coordinates to ueberzug.

The question is whether the error is on the side of nvim or lf. nvim's terminal may not be "real" enough or, alternatively, lf may be not acknowledging the nvim terminal as such. I cannot tell since I neither use nvim terminals, nor am I familiar with the internals of lf.

[davmaz]

I'm having the same problem. I've tried my 'preview.sh' command and it works perfectly if I do it manually. I checked and the lfrc has the correct statement to call the preview.sh. I'm running this on an Ubuntu 20.04.2 in the default terminal. Since I'm going to a mounted Windows directory it DOES work on one file: ' bits.go' (quotes required by Windows but I don't type them -- lf just shows the file with a prefix space). Also, whenever I try to preview another file I see "Loading..." so lf is trying to do something!

[gokcehan]

@noib3 From the screenshots, it seems that the offset is as wide as the line numbers. An easy workaround might be to disable line numbers with terminals if possible. We need more investigation to see if there is a way to take this into account on lf side to export preview pane coordinates properly. My guess is that it may not be possible. If you ask me, line numbers in terminals are not very natural anyways. You could also try manually adding 4-5 character offsets to the preview script arguments.

@davmaz I think you are having a separate issue.

[noib3]

@gokcehan I'm not sure that's the case. Those line numbers are neovim's, they are not in the terminal itself. They look like they are in that particular screenshot because they are so close. Here's another one

I'd say me and @slavistan are having the same issue, not sure about @davmaz.

[gokcehan]

@noib3 This is what I mean (orangle lines are the same length):

Isn't that the case that ueberzug attaches the image in the X window? Window contains both the terminal and neovim's additional drawings and the coordinates we report does not take into account neovim's additions. I don't know if there is a way on lf side to determine if we are running inside a terminal which does not start drawing from the top-left column of the X window. Ueberzug readme mentions it supports tmux so maybe there is a way to make this work as well. You might need explicit support for this on ueberzug side though.

In the first image, I was thinking disabling line numbers would help. Second floating term case is more difficult and I can't think of an easy workaround for that. We could mark this issue as a bug but I don't know if there's anything we can do about this on our side yet.

[SPFabGerman]

In the case of a floating terminal it might be possible to look for the enviroment variables VIMRUNTIME or NVIM_LISTEN_ADDRESS to detect if we are inside a neovim terminal or not. Then one could simply add the offset of the floating terminal to the preview offset. (Provided that the offset of the floating terminal is consistent, of course. If the offset is not consistent you would need to pass it as an enviroment variable from inside nvim to the floating terminal.)

Now terminals in normal windows are a whole different story. The problem here is, that a normal window can always move arround and be resized. So the intended position of the preview can be somewhere completetly different each time. And detecting the position of the terminal window from inside the terminal is going to be extremely hard. The only solution I could think of was to use a nvim remote command and somehow get nvim to calculate the position and offset and return it to us. But actually implementing that is probably going to be a nightmare since there a dozen of edge cases to consider. The best thing you could do, is simply not move the terminal window around (ever) and again add the correct offset, if you detect the above enviroment variables.

The big problem here comes from the fact that ueberzug works with "real" terminal coordinates, while nvim creates a "fake" terminal inside the "real" terminal. If ueberzug recieves it's coordinates from lf it recieves the coordinates from the "fake" terminal but displays them on the "real" terminal coordinates, which leads to the offset. The problem of course, is that ueberzug doesn't know from which terminal it gets it's coordinates and even if it would somehow detect, that it recieves it's coordinates from a "fake" terminal it would still have a really hard time to calculate the offset of the "fake" terminal inside the "real" terminal. So yeah, image previews in lf in nvim are not really feasible in my opinion.