`preview-tui` offsets image preview about nnn HOT 25 CLOSED

Can't reproduce this one. preview-tui just passes a hardcoded 0x0 as the offset for the icat kitten when using kitty so I'm not sure we're responsible for any offset.

from nnn.

Everything indicates that nnn is causing this offset. More precisely, preview-tui. Under the image_preview(), I am just echoing the input arguments of icat to a file and I am watching it. nnn provides the correct XxY location at the startup. but when I go through the files, nnn passes the a shifted XxY position.

Take a look:

from nnn.

Those are not the XxY offsets but rather the widthxheight. The fact that it changes to 80 x 24 is unexpected, but not directly related to the offset...

80 x 24 are the default terminal dimensions tput reports when it can't detect the actual size. So something is breaking that. I don't know what, still can't reproduce.

from nnn.

80 x 24 are the default terminal

Indeed, it seems to be the default values as they repeat to any image I select:

80 24 /home/tapyu/Pictures/Hessian.jpg
80 24 /home/tapyu/Pictures/DFT.jpg
80 24 /home/tapyu/Pictures/Bayes.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-04-20 02-17-58.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-04-24 05-11-20.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-04-24 05-55-37.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-00-18.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-04-18.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-05-39.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-09-58.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-20-50.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-24-25.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-26-19.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-34-59.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-09 09-38-19.png.jpg
80 24 /tmp/nnn/previews//home/tapyu/Pictures/Screenshots/Screenshot from 2023-05-10 21-34-54.png.jpg

Those are not the XxY offsets but rather the widthxheight.

It makes no sense, though. How could 80x24 be widthxheight if the images' ratio aren't changed? Instead, their positioning on the screen change, which makes me deduce that it is the XxY position of the image....

from nnn.

It's (supposed to be) the dimensions of the terminal pane preview-tui runs in, not the image itself. preview-tui just uses the values that tput reports, we have had issues with it reporting wrong (default) values before but that was a while ago. IDK what's wrong on your system now that breaks it.

from nnn.

I've found the problem. tput cannot correctly return the terminal dimension within a background function, which occurs in the toggle_preview() function, when preview-tui is called at the first time (without the PREVIEW_MODE set), and in preview_fifo() (when PREVIEW_MODE is set).

In your machine, check whether the tput output before calling these function and within these function. In my computer, before entering these function, tput lines is 28 and tput cols is 120 (that is correct), and within these function, tput lines is 24 and tput cols is 80.

I didn't discover yet why nnn prints the image correctly when I start this plugin, but it has something to do with the named pipe...

from nnn.

Yes on my machine it is always correct. Like I said before similar problems popped up like 2 years ago(#1228), it was fixed in a later ncurses version. What version are you on?

from nnn.

tapyu@tapyu-ThinkPad-P73 
------------------------ 
OS: Ubuntu 22.04.3 LTS x86_64 
Host: 20QRCTO1WW ThinkPad P73 
Kernel: 6.2.0-34-generic 
Uptime: 6 hours, 30 mins 
Packages: 3003 (dpkg), 14 (snap) 
Shell: zsh 5.9 
Resolution: 3840x2160 
DE: GNOME 44.3 
WM: Mutter 
WM Theme: Adwaita 
Theme: Yaru-dark [GTK2/3] 
Icons: Yaru [GTK2/3] 
Terminal: kitty 
CPU: Intel i7-9750H (12) @ 4.500GHz 
GPU: NVIDIA Quadro P620 
GPU: Intel CoffeeLake-H GT2 [UHD Graphics 630] 
Memory: 6337MiB / 23662MiB 

❯ nnn -V
4.7

from nnn.

I meant what ncurses version, try tput -V.

from nnn.

I am sorry, but what is ncurses? I've googled it but I didn't get it exactly. Is that a C library?

from nnn.

❯ tput -V
ncurses 6.4.20221231

from nnn.

OK so not the version that was found to be broken in #1228, IDK then.

from nnn.

When I startup the preview-tui plugin, the following command sequence happens:

1- preview_file is called (not in background).
1- If I call it with a selected image file, preview_file calls handle_mime (not in background)
1- it calls image_preview (not in background) (it can also call generate_preview if it isn't a jpeg file) (jpeg_preview would be a more descriptive name).
1- Finally, icat is called with the correct tput output bacause there aren't background function at the beginning. Therefore, the first image has its correct positioning (see the gif in my previous comment).

At this point, the named pipe isn't used. When it goes back to preview_fifo &, it reads from the named pipe, but with the wrong tput outputs because preview_fifo in background, which makes the remaining image previews be shifted.

from nnn.

Yes, this is all apparent. The question is why tput reports incorrect dimensions on your system.

from nnn.

I've found the problem (again)! The issue isn't exactly backgrounding the function, but is redirecting its STDOUT and STDERR to /dev/null. In this MWE shell script:

#!/bin/sh

fun(){
echo "That is a shell function that will run in background" >> $HOME/test.log
echo "inside the function: tput lines is $(tput lines)" >> $HOME/test.log
echo "inside the function: tput cols is $(tput cols)" >> $HOME/test.log
} >/dev/null 2>&1

fun "test" &
sleep 1
echo "in the shell script scope: tput lines is $(tput lines)" >> $HOME/test.log
echo "in the shell script scope: tput cols is $(tput cols)" >> $HOME/test.log

In my machine, I get

❯ \cat test.log
That is a shell function that will run in background
inside the function: tput lines is 24
inside the function: tput cols is 80
in the shell script scope: tput lines is 28
in the shell script scope: tput cols is 120

That is the bug's origin.

from nnn.

If you remote >/dev/null 2>&1, we get

❯ \cat test.log
That is a shell function that will run in background
inside the function: tput lines is 28
inside the function: tput cols is 120
in the shell script scope: tput lines is 28
in the shell script scope: tput cols is 120

from nnn.

I have no idea why tput loses the terminal information within a function when we discard its STDOUT and STDERR.

from nnn.

Right, which is why we removed it in #1431. Are you using preview-tui from master?

from nnn.

I just ran this command in the installation procedure. I honestly cannot explain how it happened, but it didn't downloaded the up-to-date plugin shells... I just run it again and all the shell scripts now are up to date and preview-tui is working properly... If I have a clue what happened, I put a comment here... Thank you very much anyway.

from nnn.

OK I thought you were on the latest version since you were linking to functions from the master version... Yes the getplugs script is designed to download the versions of the plugins that were latest at the point of the release of the nnn version you're using. When reporting issues it is always best to actually use the master version however (getplugs master can be used for this).

from nnn.

I thought you were on the latest version since you were linking to functions from the master version

Concerning the plugins, me too.

When reporting issues it is always best to actually use the master version however

As far as I can remember, I installed nnn from the Ubuntu package manager, apt, and downloaded the plugins from the master branch, but I probably made some mistake in this last step.

from nnn.

@luukvbaal I discovered from where I got the outdated plugins! It tuns out the this shell script is not downloading most updated plugin versions.

Take a look. From the master branch and on another machine (I have two computers), this script is downloading some previous version of preview-tui which contains the 2>/dev/null

I didn't look this script yet, but there is probably a bug in it.

from nnn.

The problem is because this machine runs on Ubuntu 22.04, which provides

❯ nnn -V
4.3

The file https://github.com/jarun/nnn/releases/download/v4.3/nnn-v4.3.tar.gz is outdated and provides a bugged preview-tui.

Shouldn't be better to always provide the most updated plugins version regardless the nnn version?

from nnn.

Yes like I said the getplugs script doesn't download the latest version by default #1746 (comment)...

Shouldn't be better to always provide the most updated plugins version regardless the nnn version?

I think so too, @jarun disagrees.

from nnn.

Shouldn't be better to always provide the most updated plugins version regardless the nnn version?

The plugins might be updated in a way that makes it work only on master nnn and break on older nnn version. I don't think this has happened much though. But both sides (fetch master vs stable) has downsides.

from nnn.