Nnn: kitty preview plugin needs to be stabilized

[midexe6380]

kitty preview doesn't always work

for example
get last commit https://github.com/jarun/nnn/commit/0c916ae7b024c961df1ab1797035ee80501f66e3
git clone https://github.com/jarun/nnn.git
make
make install
get test repository with last commit https://github.com/wireapp/wire-desktop/commit/13e69df98f2c8c79ad61cd8326f4a1afc2effd04
git clone https://github.com/wireapp/wire-desktop.git
cd wire-desktop
cd resources
cd macos
cd entitlements

didn't display folder entitlements and file child.plist
although bat and exa separately perfectly display the contents of the file and folder
for clarity, I attach a video
https://youtu.be/2f5m68YhTg8

here I show that bat can normally view the file, but for some reason does not do this
https://youtu.be/2f5m68YhTg8?t=17

for comparison:
ranger displays this
https://youtu.be/2f5m68YhTg8?t=26

[jarun]

@leovilok please take a look.

[leovilok]

hum, I get the same issue with preview-tui, I suspect that our "smart" pointer comparison to check if we actually moved the cursor has a few false positive on string reuse. I'll look into this tomorrow. Thanks @midexe6380 for reporting!

[jarun]

From the video it seems the problem is the timestamp of the directory and file matches. An easy fix could be checking if the mode matches. But if there's a directory within a directory with the same timestamp we will still see this issue.

But I would say that's still better than the timestamp. I will think some more on this.

[jarun]

struct entry is 40 bytes (much smaller than the 4K max path length). I would suggest we store the whole thing and do a memcmp which is pretty fast.

[jarun]

Note that there's still the worst case where everything matches but I believe that's a long shot. Someone has to prep it with prior knowledge.

[jarun]

@midexe6380 please confirm if the latest patch works as you expect.

[midexe6380]

@jarun now is working
but there were other problems

example
get test repository
git clone https://github.com/timvisee/ffsend.git
cd ffsend/pkg/scoop/
ffsend.json file shows as binary without preview
https://i.imgur.com/DTMm2Hr.png

[midexe6380]

also if I run two or more nnn instances kitty preview doesn't work at all

[midexe6380]

kitty preview plugin is very unstable 🙃

[jarun]

@midexe6380

ffsend.json file shows as binary without preview

Plugins are indicative. We do not guarantee a plugin should work for everyone on all machines and if it doesn't we will spend our personal time to attend to user problems with plugins. These are trivial scripts and almost isolated from core nnn.

Can you try to look into the plugin code and debug yourself? The logic is pretty simple - do a file to detect the type and render. Maybe we need to check the extension and render?

also if I run two or more nnn instances kitty preview doesn't work at all

That also has a simple explanation. You are trying to write to the fifo file from 2 instances of nnn.

@leovilok can we do something for the second problem?

[jarun]

Reopening this for the second problem - _also if I run two or more nnn instances kitty preview doesn't work at all_.

@leovilok ~I think we need to use on the fly FIFO files for the plugins and the plugins should use NNN_FIFO instead of the fixed path. We can use -f to do that.~

[jarun]

I completely forgot about NNN_FIFO=$(mktemp -u) we discussed earlier.

@midexe6380 you have to use random tmp files. Documentation here: https://github.com/jarun/nnn/wiki/Live-previews#setting-up-nnn_fifo

[leovilok]

Sorry, I was disconnected for a while, I guess it's the downside of living in a rural area (but is it really a downside?).

ffsend.json file shows as binary without preview

@midexe6380 In this plugin (and in preview-tui too) we use the command file -b --mime-type to select a previewer, and only preview text files when a mime type matching text/* is reported. A JSON file seems to have a mime type of application/json, and there are probably a few other text filetypes that don't have a text/* mime type. I will write a general fix for that, using file -b --mime-encoding logic, tonight (if my connexion holds :smile:)

also if I run two or more nnn instances kitty preview doesn't work at all

If you run 2 instances of nnn with the same NNN_FIFO path, they will write to the same FIFO, so you can have 1 previewer for 2 instances (that will get updated whenever the hovered file changes on any of the 2 nnn instances).
As @jarun said, read the docs here on how to have a different FIFO for each nnn instance.

If you open 2 previewers windows for the same nnn instance, the FIFO output lines (hovered file path) will probably get spread to both previewers, depending on your system's FIFO implementation. So IDK why you would want to do that, should we find a way to prevent spawning 2 preview plugins for the same FIFO? (there is probably one way to do that using fuser).

kitty preview plugin is very unstable

@midexe6380 Did you notice any other issue? Does it crash?

@jarun the "fly FIFO" idea is close to what we already discussed (I proposed a tmp autofifo flag), and yes, it can be worked around using NNN_FIFO=$(mktemp -u) (now documented). But I think that we should still keep this idea in mind in case users keep reporting bugs about that despite the documentation.

[jarun]

I think we should have it. Please raise the PR.

[leovilok]

@jarun see #588

[midexe6380]

I'm sorry it took me so long to answer.
I had problems accessing the Internet.
Just like @leovilok

Sorry, I was disconnected for a while, I guess it's the downside of living in a rural area (but is it really a downside?).

@jarun I can’t use two plugins at once (quitcd and kitty preview)
https://github.com/midexe6380/nnn/blob/master/misc/quitcd/quitcd.bash_zsh#L24

I did as it is written there, but nothing worked for me.
maybe I'm doing something wrong
https://github.com/jarun/nnn/wiki/Live-previews#setting-up-nnn_fifo

I completely forgot about NNN_FIFO=$(mktemp -u) we discussed earlier.

@leovilok I know several text mime types (maybe there are others).
text/plain
application/x-yaml
application/json
application/x-shellscript
text/vnd.qt.linguist

A JSON file seems to have a mime type of application/json, and there are probably a few other text filetypes that don't have a text/* mime type.

@leovilok Yes. There are a lot of problems there. For example one of the most obvious problems is slowing down the nnn.

Did you notice any other issue? Does it crash?

for example
git clone https://github.com/timvisee/ffsend.git
cd ffsend/res
and find demo.svg file.
At this time, the plugin will hang while the command to rendering the svg image.

nnn positions itself as fast file manager.
If @jarun uses nnn on Raspberry Pi, the launch nnn with kitty preview will be very slow for him
but your kitty plugin is many times better 🐱 than the built-in ranger
ranger starts to eat up RAM until it runs out.

Аnd also there are other problems and most likely this is a kitty terminal problems.
https://github.com/kovidgoyal/kitty/issues/2016
and
https://github.com/kovidgoyal/kitty/issues/1681

and since nnn is launched in kitty, these problems are inherited along with it.
When closing nnn the preview mode may not always close also this bug is difficult to catch and reproduce.

[midexe6380]

@jarun Can nnn control the kitty terminal so that it closes the preview when a file is opened?

[jarun]

Maybe if we close the fifo? @leovilok ?

[0xACE]

Regarding the script waiting for generating a preview of the while: You can fix it yourself, infact I think preview-tabbed is handling this fine.

I can’t use two plugins at once (quitcd and kitty preview)
https://github.com/midexe6380/nnn/blob/master/misc/quitcd/quitcd.bash_zsh#L24

Yes you can, I'd start by putting the NNN_FIFO declaration on a seperate line before running nnn (assuming the shell handles it as a variable, otherwise try export)

Yes. There are a lot of problems there. For example one of the most obvious problems is slowing down the nnn.

What?? Where is nnn being slowed down?

Iirc one of the plugins is using vim as a pager, I would highly recommend you change it back to less as vim will greatly slow down with syntax highlighting for long lines (explains your svg situation), (infact vim starts much slower than less)

a rpi would be bottle necked if you throw things at it that much, maybe you want to SPECIFICALLY for your setup set a NICE level for the process the preview script is spawning, that way the rest of your system doesn't freeze up for a low priority preview... The time you spent writing these detailed errors could've been time you spent on fixing the problem and sending a PR, I would argue you are capable of doing this.

He uses the rpi, hence the design restrictions in the code base... nnn itself is very optimized at the cost of the clarity of the code, I'd argue the optimizer could do this job for us, but meh why start fires when it's not even smoking yet...

Off-topic: If performance is a problem, wouldn't a lightweight terminals such as st fit better?

I ran out of time writing this message, I hope i helped. peace

[leovilok]

I did as it is written there, but nothing worked for me.
maybe I'm doing something wrong
https://github.com/jarun/nnn/wiki/Live-previews#setting-up-nnn_fifo

If PR #588 is merged it will be easier, you'll just have to add a nnn option (maybe -a) and a temporary FIFO will get autogenerated.

@leovilok I know several text mime types (maybe there are others).
text/plain
application/x-yaml
application/json
application/x-shellscript
text/vnd.qt.linguist

This should be fixed in master, as we now use file -b --mime-encoding to detect binary files.

@leovilok Yes. There are a lot of problems there. For example one of the most obvious problems is slowing down the nnn.

The preview window might be slow, and might lag behind, but it should never slow domn nnn (the main program window).

for example
git clone https://github.com/timvisee/ffsend.git
cd ffsend/res
and find demo.svg file.
At this time, the plugin will hang while the command to rendering the svg image.

The image is processed by kitty's icat, which itself convert it from svg using inkscape.
This process is quite slow, and as hovered files are previewed sequentially, if you go though e.g. a list of svg file, they will stack up in the pipe, and the previewer will get late. preveiw-kitty relies on each filetype previewer being fast enough, but kitty's icat can be slow sometimes. I'm tempted to either:

1. set a timeout for icat, but you would never see images that are slow to render, even after waiting a bit,
2. preview svgs as text (and maybe only show metadata for huge images)
3. start kitty's icat in the background, and kill it if it's still loading when a new file arrives from the FIFO, but this would add more dependencies.

What do you think?

nnn positions itself as fast file manager.

nnn itself should always be fast, file previewers might be slower, as some files are inherently slower to render, but the previewer should never hang nnn itself.

Аnd also there are other problems and most likely this is a kitty terminal problems.
kovidgoyal/kitty#2016
and
kovidgoyal/kitty#1681

and since nnn is launched in kitty, these problems are inherited along with it.

If kitty has to many issues, you can try to take inspiration from preview-kitty to write a previewer for another terminal. There are other image capable terminals, if it's what you need:

• some terminals have sixel support
• terminology has its own image support
• on some teminals you can use the w3mimgdisplay (or alternatively Überzug) hack
• there are some ascii art/unicode blocks image to text terminal converters

When closing nnn the preview mode may not always close also this bug is difficult to catch and reproduce.

Are you opening the preview window and quitting nnn before the preview window is opened? Beyond this I don't see how this could happen (unless you had several nnn instances writing on the same FIFO, but I believe you will get that fixed soon).

[midexe6380]

@leovilok

• preview svgs as text (and maybe only show metadata for huge images)

I think it will be the best option

Are you opening the preview window and quitting nnn before the preview window is opened?

No. I will try again to reproduce the case when this happens and write to you.

@0xACE
Kitty uses Inkscape for rendering svg (nnn has nothing to do with it).
Vim not used. Used bat.
I don't think that because of the plugin in nnn, the author of kitty will change the source code that relates to viewing images.
I don't have enough knowledge for fixing the problem and sending PR but I can make donation to the development of nnn.
I have no performance issues. I use kitty and alacritty. I just wanted to warn that if someone uses the preview, it will lead to a drop in performance.
I hope I have answered all your questions. Peace 🌎

[leovilok]

@midexe6380 please try preview-kitty version from PR #591, (direct link).
It should fix issues with slow rendering previews.

[midexe6380]

@leovilok
it's really works
amazing kitty 😻️ plugin!
thank you very much

[midexe6380]

@jarun Can nnn control the kitty terminal so that it closes the preview when a file is opened?

Maybe if we close the fifo? @leovilok ?

is it possible to do this or not?

[leovilok]

I think that closing the FIFO is not a good idea, as it's currently the only way for the plugin to know when nnn exits, but it would work for this need.
Currently, the only information that get down the FIFO is hovered file path, so there is no ways for preview plugins to know anything else about what happens in nnn, so it can't be implemented right now without adding some support for that inside nnn core (and we want to keep nnn's core minimal).

Well I guess that we could cheat by tracking processes reading hovered file, but there is a lot a false positive potential.

[midexe6380]

Ok. I got it. Thanks.

[midexe6380]

I think I don't need to delete FIFO.
When you close the file, open the preview window again.
ls
close
new

[jarun]

Guys, all the details should in the wiki or the plugin itself. Please ensure that happens. We shouldn't have to go through this again.

[leovilok]

@midexe6380 As I said, the preview plugin have no clue of when files are opened, edited, etc. in nnn. Sorry, but I won't implement preview pane close on file open.

That said if you want to implement it yourself, go ahead. I can assist you if you need.

[jarun]

I'm fine with this.

[midexe6380]

@leovilok
@jarun
thank you very much 😀️