Nnn: kitty preview is not updated when file is modified

[midexe6380]

I noticed that after editing the file, kitty preview stops working.

1) / find any text file
2) e edit this text file
3) done! kitty preview don't refresh.

[jarun]

Is the file executable anymore?

Also, see the diff with the version on master. If there's no difference, it should work.

[jarun]

I am closing the defect as I strongly believe the problem has to be any of the above 2. If it had worked before there's no reason it wouldn't work if

• the fle is executable and
• the content is the same (it's possible that you may have inadvertently modified it)

[midexe6380]

@jarun File is not executable. As plain text. I didn't change him inadvertently. This behavior only applies to search results. Have you tried searching and then editing?
@leovilok What do you think about this?

[jarun]

Ahh, I got it all wrong from your subject-line:

kitty preview is stopped

should be _kitty preview doesn't refresh when file is updated_

I think the reason may be the hover isn't changed.

Also, does it work when you hover to another file?

[midexe6380]

sorry
english for me is not native language

Also, does it work when you hover to another file?

yes

[jarun]

@leovilok what's the best course of action here?

[jarun]

@midexe6380 I gave it a thought and I think we are not going to support this. Primary reasons:

• we do not watch the directory in _type-to-nav_ mode (as refreshing a filtered view is confusing)
• nnn merely invokes the opener, it doesn't care which utility you open it with. To support this scenario we will need to watch the hovered file which I think is a overhead we can live without.

We will document this.

[jarun]

Document updated at commit f5b5cf5fd71fb7a5286cc0c427fa2462bd4b7ad3.

[jarun]

@midexe6380 I tested and can confirm that pressing ^L to redraw the view will update the preview without changing the hover. Updated the docs to reflect the same.

[midexe6380]

@midexe6380 I tested and can confirm that pressing ^L to redraw the view will update the preview without changing the hover. Updated the docs to reflect the same.

yes
but then the search results will be reset

[jarun]

Yes. If that's a problem just hover to next and back.

[jarun]

@leovilok does it make sense to add a keybind to forcibly write the hovered file path to the FIFO file?

[0xACE]

Just want to state: I was in a folder with preview enabled. While torrents were being downloaded: the folder was refreshing, it keept re-previewing the file that was hovered over without user interaction.

@leovilok does it make sense to add a keybind to forcibly write the hovered file path to the FIFO file?

I thought about this last night, as I kept clicking into the nnn window, but I didn't think of a solution to this problem at that time... I think a key is a "potential" solution, but I'm more curious about a more complete solution (if that's even possible without modifying the terminal)

[leovilok]

@jarun Or maybe force a FIFO write when inotify updates the current path?

[jarun]

maybe force a FIFO write when inotify updates the current path?

In _nav_to_type_ mode or filtered view we do not have it. Also, currently we subscribe to dir updates and if one is there we refresh. Enabling this would mean we'll have to take the granularity to a file level which I do not want to do just for refreshing previews.

[jarun]

And for people like me who always use nav-to-type (even @midexe6380 has mentioned search results), it's of no use. I think the best option is to provide a keybind to rewrite the file path to the FIFO.

[jarun]

Maybe this is a better suit for F5?

[leovilok]

F5 is indeed commonly associated with a refresh action (but maybe something more like ^L ...). Maybe | (but you might need something that won't get in your way in seach mode ...).

I also want to let you know that I've been exploring the other way around this issue: using entr to update the preview on file change from inside the preview plugins ... but it seems that there would be a lot of added complexity, and I still don't have anything working reliably.

[jarun]

| is a good choice.

[0xACE]

I also want to mention, the same problem exists for mouse operations... clicking the currently hovered file, does not update the preview.

[jarun]

If you left click on the file _and it's modified_, it should be updated. move_cursor() is called for left click. See line 5474. If it's not, that's something for you to debug. ;)

[jarun]

The reason it's not updated is - we do not reload the file.

[0xACE]

I should've clarified, when multiple sessions of nnn share the previewer, you would have to select another item to enforce it to re-preview the original file.

Anyhow it's not a problem per se. I just brought it up since I figured it's relevant.

[jarun]

@0xACE can you confirm if commit 61b4416e088e90b947ac6cbfd4b798f67ac4043c fixes your issue?

[jarun]

@midexe6380 see commit 1dbbc45c7843ce28056786c604430a68f67f56ae for your issue. You can now press | to refresh the preview without losing the filtered results.

[midexe6380]

Magic! It's black magic 🔮
kitty plugin can react at random.

more specific
if you create a new file in folder ~/ram/nnnbleedingedge, kitty plugin will not refresh and need will be press |
but if you create new file in .. ~/ram directory, kitty plugin automatically will be refresh without |

demo
https://youtu.be/IAD0sr54RyY

[0xACE]

@0xACE can you confirm if commit 61b4416 fixes your issue?

won't be near a computer for the next 2 weeks. I'll test it once i get a chance.

[jarun]

kitty plugin can react at random

Not really. We subscribe to events in the current dir. So when your results are not filtered, the current dir will be refreshed if you create a new file in it. That doesn't apply to file created within subdir.

[leovilok]

@midexe6380 it's not black magic, it's just that the preview plugin only updates its view when nnn itself updates, and nnn updates only when the current dir is updated.

[midexe6380]

@0xACE can you confirm if commit 61b4416 fixes your issue?

won't be near a computer for the next 2 weeks. I'll test it once i get a chance.

it works for me.
nnn is positioned as terminal file manager.
why do need a mouse?

[midexe6380]

@midexe6380 it's not black magic, it's just that the preview plugin only updates its view when nnn itself updates, and nnn updates only when the current dir is updated.

this is a little strange behavior nnn

[midexe6380]

Perhaps someone likes this behavior.
I don't know...

[midexe6380]

Anyway thank you @jarun @leovilok

[leovilok]

@midexe6380 I'll try some inotifywait based fix

[midexe6380]

@leovilok You mean https://www.archlinux.org/packages/community/x86_64/inotify-tools/

[leovilok]

Exactly, but this means even more asynchronous madness ;)

[jarun]

Exactly, but this means even more asynchronous madness ;)

Why do we need to do this from a script? Mostly people watch images in a preview. If they are editing a file and want to view the edited version we have provided |. Somehow I now get a feeling that we have this new toy called preview and we are wasting a lot of time trying to add more and more finesse when we can actually work on something more useful.

[midexe6380]

work on something more useful.

this is really useful

because this puts nnn on a par with ranger

[jarun]

@midexe6380 if previews is the feature which tells you how good a file manager is, why are you interested in nnn when ranger already has the feature?

(It's a serious question, I would like to understand)

[midexe6380]

@midexe6380 if previews is the feature which tells you how good a file manager is, why are you interested in nnn when ranger already has the feature?

because ranger is slow
nnn with kitty preview makes file access easier without affecting performance
in addition, nnn is laconic
I mean the number of keys pressed in nnn is several times less than I should press in ranger
and many other advantages...

of course, nnn has disadvantages, but these disadvantages can be eliminated over time
in ranger they can not be eliminated, because they are at the level of the application architecture

[jarun]

nnn has disadvantages

some examples (other than previews)?

[jarun]

While you respond, let me clarify why I tend to resist fancy features. Before I started writing it, I explored both terminal and GUI FMs. I found several nice and fancy ones but none performant enough to run smoothly on a memory+power constrained device. I set to write something that does stuff others can't. So nnn pulls off du or find & list without a sweat. Icons, colors, previews etc. were never our selling point. It was meant for power users who can get the most out of text. Of course, with popularity came public demand and features like previews got included (@leovilok and @toddyamakawa did a great job there). However, the original goal of the project to remain a performant tool for power users is still there. Lately we have been spending a lot of time on the preview feature and the issues are diverse. It's not just this one. Hence, I am concerned that we are spending a lot of time fixing these. I would really appreciate users to pitch in, discuss and raise PRs to fix plugin (which are just scripts) issues.

[leovilok]

The main design idea of NNN_FIFO (wich allowed writting preview plugins) was to add as few stuff as possible into nnn, never slow it down, and write fancy stuff externally to nnn (as plugins or external scripts). While this allows to keep nnn itself minimal, and with uncompromising performances, this also means that preview plugins don't have much infos to deal with, and sometimes have to work around that.

So with this design, preview script are outside of nnn, this allows to tweak them at will, to use other external powerfull tool ... but we also have to deal with how those tools play together, and do that in shell ... So it's naturally harder to make it reliable.

As for preview autoupdate on file change: maybe if you really need it you can use autoupdating programs as file previewers (e.g. a good editor for text file, nnn itself for directories ...).

(I'm still struggling to write something reliable with inotifywait, and I fear that if it's so hard we will always have issues with other shell/platforms.)

[midexe6380]

I tend to resist fancy features

This is correct! This is the only way to keep the nnn core fast and lightweight

It was meant for power users who can get the most out of text

power users should suffer and there should be no convenience for them
for example, with icons, it would be easier to take a quick look at the contents of a folder, that is, it would be easier to find files if they were marked graphically
but icons and ligatures will make slow nnn
therefore there is always some balance between performance and convenience with beauty

Icons, colors, previews etc. were never our selling point.

if not your selling point, why made kitty preview?
most likely because it's convenient

Of course, with popularity came public demand and features like previews got included (@leovilok and @toddyamakawa did a great job there).

so it turns out that under the pressure of the community you shifted the initial emphasis?

some examples (other than previews)?

I had one in one the same problem as @0xACE , but @0xACE write issue faster than me. I need more time to test whether it works correctly on all variants. And also nnn doesn't always pass the plugin the file on which it is currently located, perhaps I did not understand this. If you allow me I can create an additional issue about this.

I wish the nnn project prosperity 🌻
Amazing guys 🎉
@jarun personal success 💪
@leovilok all the best 🚀

@0xACE Peace 🌎

[jarun]

power users should suffer and there should be no convenience for them
with icons, it would be easier to take a quick look at the contents of a folder

Not really. When we say power, think in terms of 1000s of files. Not a directory with 20 files. Say you are searching for an executable. There can be many and you can't just rely on the icon or color. And in that _full_ directory you can't keep scrolling. What we try to emphasize in nnn is - the only way to reliably find a file is by it's name. So you filter. We even support PCRE regex. That is the only way to get to that file accurately. For an organized user, 50 videos will be together and 50 documents will be together. And there is no way to determine by color or icon which one you are looking for.

if not your selling point, why made kitty preview?
most likely because it's convenient
so it turns out that under the pressure of the community you shifted the initial emphasis?

Because we have enough users (from desktop or laptop) asking for it now. If you noticed, the NNN_FIFO feature can be compiled out. This ensures people who do not or cannot use them don't need to burden the CPU.
But my current concern is the time we are spending on it. While devs are trying to help users, I have to keep 2 things in mind - we have other interesting features to add as well and the people I work with do it spending their own free time. I had been working with guys in academics who would spend all their time in open source contributions. That's something I strongly discourage. Previews is one of those features where we have spent a lot of effort already. I have tried to address your concern despite a very very busy personal schedule yesterday but as I can see it's not to your liking. So I prefer in these cases that users get their hands dirty rather than @leovilok (who is kind of working on this alone for several weeks) spending more time working on more complex solutions.

I had one in one the same problem as @0xACE

It's was a bug and I have addressed this already. My question was more on user experience, features etc.

[jarun]

@midexe6380 I have replaced | with Esc to send hovered file path to FIFO.

[leovilok]

@jarun I'm not sure how you differentiate Esc and Alt+key, but well done.

[jarun]

See nextsel().

[toddyamakawa]

so it turns out that under the pressure of the community you shifted the initial emphasis?

I don't have the full history here, but @jarun has constantly rejected previews as an nnn feature. To this day, previews are not built-in to nnn. nnn just writes stuff out to a FIFO. It just so happens that previewers read that FIFO.

This FIFO is so much more powerful than a previewer because it has the entire history of everything that is accessed. This would enable users to write a plugin that jumps in to different directories in the session's history.