Nnn: Can't get preview to work

Created on 31 May 2020  路  45Comments  路  Source: jarun/nnn

Environment details (Put x in the checkbox along with the information)

[x] Operating System: MacOS 10.14.6
[ ] Desktop Environment:
[x] Terminal Emulator: iTerm2
[x] Shell: zsh
[ ] Custom desktop opener (if applicable):
[ ] Program options used:
[ ] Configuration options set:
[x] Issue exists on nnn master

NNN_PLUG=f:fzcd;o:fzopen;z:fzz;d:diffs;t:treeview;v:preview-tui
NNN_FIFO=/tmp/nnn.fifo
TMUX v3.1b
nnn v3.2

Maybe I'm just dumb, but I can't get the preview to work.

  1. I hover on file
  2. Press ;
  3. Press v
  4. nnn just flickered but nothing show.. what did I miss? 馃

Please help. Thank you

question

Most helpful comment

@leovilok I made it future version proof to version 9. See commit 56eea7e195e98eedca374cfc24cc43afe73d43db. By the time tmux reaches v9 we can remove the check. ;)

All 45 comments

Did you run tmux first and then start nnn from within?

Run tmux first.. I mean start nnn inside tmux session

What is the output of tmux -V?

tmux 3.1b

Also, please try the following patch:

diff --git a/plugins/preview-tui b/plugins/preview-tui
index 7872b07..e467236 100755
--- a/plugins/preview-tui
+++ b/plugins/preview-tui
@@ -73,7 +73,7 @@ if [ "$PREVIEW_MODE" ] ; then
     exit 0
 fi

-if [ -e "${TMUX%%,*}" ] && [ "$(tmux -V | cut -c6)" -eq 3 ] ; then
+if [ -e "${TMUX%%,*}" ] ; then
     tmux split-window -e "NNN_FIFO=$NNN_FIFO" -e "PREVIEW_MODE=1" -dh "$0" "$1"
 else
     PREVIEW_MODE=1 $TERMINAL -e "$0" "$1" &

Forget the patch in that case. The issue is somewhere else.

Try the following:

  1. tmux
  2. nnn -a
  3. ; followed by v

What do you see?

I need fast follow-up here. Don't have a lot of time in hand. Plugins are indicative. In most cases we request users to modify and suit themselves. I am offering some help here because it's a very fresh plugin.

ok so I goofed up.. for some reason the preview plugin wasn't there when I first install.

Now that it's there I got some error

terminals database is inaccessible
tput: unknown terminal "tmux-256color"
tput: unknown terminal "tmux-256color"
head: illegal line count -- -1

Try:

echo $TERM

I think there should be some check whether the plugin exist when invoked. There was no error.

echo $TERM
xterm-256color

I think there should be some check whether the plugin exist when invoked

There's a check for the plugin dir. However, we can't check for the existence of each plugin. The mechanism works not only for plugins but also for running commands as plugins. So if you don't install a plugin and try to run it, nnn would try to run it. As long as nnn does not crash, I don't see a problem.

Also it's a one-time install. Can't add a check that runs every time because user wants to use a plugin that he hasn't installed.

I have the same: xterm-256color.

I think it has to do something with some stray tput command you have somewhere. Definitely not an nnn issue. Please solve local environment issues yourself.

It seems that you don't have a terminfo entry for tmux-256color, try running the tput command in tmux, you probably already see the error message. This is not related to nnn, but if it's the default on MacOS we'll have to write a workaround (we use tput, from ncurses, to get the terminal's row/columns). But I think that the issue is with your system because without a working terminfo for tmux, no ncurse based terminal app should work well.

@leovilok apparently nnn don't like tmux-256color so I've changed all back to xterm-256color. Solved

Well we don't do anything directly with $TERM, we just use tput (part of ncurses) in a few plugins ... but good to know it fixes it for you.

On Sailfish OS, I observe the same flickering behaviour @kuntau reported. That's with nnn -a after running tmux, and preview-tui is in the plugins folder.

# nnn
export NNN_COLORS='4321'
export NNN_PLUG='t:preview-tui;v:_viu $nnn'
export NNN_FIFO='/tmp/nnn.fifo'

tmux next-3.2
nnn 3.2
xterm-256color using havoc terminal (but same issue in other terminals that use xterm or screen)

The plugin works out of the box on my computer with git nnn, Tilix and tmux 3.1b, so I suppose I might just be missing a dependency or something. I tried changing $TERMINAL in the script but that will open a new terminal for previews instead of the pane preview.

The problem is tmux next-3.2. The check we have currently is:

"$(tmux -V | cut -c6)" -eq 3

which fails. I also compiled tmux from source and faced this problem. You can hack the code to change the version to "3.2". That's what I did.

Excellent, thanks! For testing, I just removed the version check you quoted from preview-tui and that works. In my case it might be easier to do just that instead of changing the version tmux reports.

@leovilok and @KlzXS any way to make the check more accurate?

Maybe check if next is present?

For reference, works pretty well on the phone (and from SSH too of course): https://asciinema.org/a/336296

I am happy.

I get these weird warnings with tree, but I suspect it's due to the fact that I had to use Node.js tree-cli instead of the usual tree. I think it's a bit slower which could cause issues with the fifo file before it refreshes.

@leovilok and @KlzXS any way to make the check more accurate?

@jarun I use my modified version with this regex.. so far it worked on all tmux version variations

TMUX_VERSION=$(tmux -V | sed -En "s/^tmux[^0-9]+([0-9]+(.[0-9]+)?).*/\1/p")

if [ -e "${TMUX%%,*}" ] && [ "$(echo "$TMUX_VERSION >= 3.0" | bc)" = 1 ] ; then
....

@Kabouik we are going to link it from the wiki or plugins doc. Is that fine?

@kuntau please raise the PR.

@jarun The asciinema cast, you mean? If so, wait, I'll make a better version with true colors enabled (viu previews were rendered without true colors in tmux).

Perhaps it'd be best to solve the warnings with when previewing dirs too (but I believe this has to do with Node.js tree-cli or nnn expecting faster response time, I'm not sure).

Yes, the asciinema cast. A better version would be great! Thanks a lot in advance!

Here is the new one: https://asciinema.org/a/r3cDlyp2UZ0kLbO5GavPGcM8z

Now the cast shows contexts in action, directory preview, text preview, text edition in $EDITOR (micro here) and image preview (using viu).

I improved the description a little to make instructions more accurate, and to mention that the viu previews looked better on the phone, asciinema's conversion degraded them.

@Kabouik it's a shame that you have those "Terminated ..." messages, try this replacement:
~diff
-kill %- %+ 2>/dev/null
+kill %- %+ 2>/dev/null && wait %- %+ 2>/dev/null
~

@kuntau this might be a bit simpler, but not v4.0 proof:
~sh
if [ -e "${TMUX%%,*}" ] && tmux -V | grep -q '[ -]3.' ; then
~

Awesome, that improves it a lot @leovilok! The warnings still show up if I scroll too fast, I'm guessing it happens when I hover a new directory while the previous was still being fetched. If that's not easily flexible, I am happy to make another cast now, otherwise we can try to fix that too.

@leovilok I made it future version proof to version 9. See commit 56eea7e195e98eedca374cfc24cc43afe73d43db. By the time tmux reaches v9 we can remove the check. ;)

Nice @jarun.

I'm guessing it happens when I hover a new directory while the previous was still being fetched

Note this also causes issues with viu because if you scroll very fast (using key repeat on DownArrow), viu will not skip files you did not stop onto, but instead queue all of them before rendering the file you actually wanted to target.

I think it would be good to implement a way to interrupt a preview still loading when another one is triggered on another file. When the previewer is not instantaneous (heavy work or old machine), this would likely solve the issues such as those detailed here for tree-cli and viu.

@Kabouik interrupting is already implemented, just use viu "$1" & instead of viu "$1".

Thanks all for your help. All issues fixed, so here is a clean cast for the wiki or the plugin page: https://asciinema.org/a/336443

The performance of nnn is really phenomenal (remember that it's a phone), and tree-node-cli is also much faster than the module I tried before.

Thanks for the cast!

Nice. I tried to make a .svg out of it so you could embed the animation in the readme (it's not obvious that there is an animation if you click on it), but so far it's not working.

I'll post an update here with the file when/if I succeed.

It might be easier to turn it into a .gif?

Even the asciicast is fine.

@leovilok I made it future version proof to version 9. See commit 56eea7e. By the time tmux reaches v9 we can remove the check. ;)

Does it work with tmux versions containing a letter too?

kabouik@xiaomimi-solus ~ $ tmux -V
tmux 3.1b
kabouik@xiaomimi-solus ~ $ tmux -V | grep -q '[ -][3456789]\.'
kabouik@xiaomimi-solus ~ $ 

As a result the plugin tries to run xterm on this machine. Again I can just remove the version check manually since I know I use a version >3.0, but just wanted to report this corner case.

@leovilok help!!!!!!!!!!!!!!!!!!!! Guys can't you google search and raise a PR? Because if I want to fix it I'll do that.

@Kabouik it works:
~
$ check () { printf '"%s": ' "$1" ; echo "$1" | grep -q '[ -][3456789].' && echo true || echo false; }
$ check "$(tmux -V)"
"tmux 3.1b": true
$ check "tmux 2.3.1b"
"tmux 2.3.1b": false
$ check "tmux next-3.0"
"tmux next-3.0": true
$ check "tmux next-4.1"
"tmux next-4.1": true
$ check "tmux 2.27-3"
"tmux 2.27-3": false
$ check "tmux sdfghjk 3.42.3.1.4"
"tmux sdfghjk 3.42.3.1.4": true
~

Sorry jarun, regex is out of reach for me so I did try to fix it myself using some doc, but didn't succeed Turns out the issue was probably somewhere else anyway given what leovilok just showed (thanks by the way).

Nice. I tried to make a .svg out of it so you could embed the animation in the readme (it's not obvious that there is an animation if you click on it), but so far it's not working.

I'll post an update here with the file when/if I succeed.

I finally managed to convert it to .svg for automatic animation without going to asciinema.com, but the file is a bit large (6 MB), which might be inconvenient for small connections so maybe it's not a good idea anyway. I just wanted to update this post as I said I would, though. In any case, svg or not, I will try to make another asciicast in the future if you think that could be useful, now that preview-tui has been significantly improved in the past few days.

asciicast-nnn.zip

In any case, svg or not, I will try to make another asciicast in the future if you think that could be useful

That's a good idea. We can have a demo of the latest features, probably with better image rendering etc.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

amanjitsk picture amanjitsk  路  7Comments

akimdi picture akimdi  路  6Comments

CantoroMC picture CantoroMC  路  4Comments

harriott picture harriott  路  6Comments

leovilok picture leovilok  路  3Comments