ToDo list

[jarun]

Rolled from #1133.

Cooking

• support macOS iterm2 in plugin preview-tui (Support OSX iterm2 in preview-tui by using split pane #1196)
• use selection at native command prompt with %j and %J
• scroll strings longer than columns in rename/new prompts (Rename file with a long name #1213, Long input is truncated in rename prompt #279)
• batch rename symlink targets in listing mode (batch rename find/fd files #1214)
• picker mode: enable auto-proceed
• picker mode: don't pick hovered file on Enter if selection exists
• picker mode: fix issue in plugin fzopen when used to pick files
• send file to explorer FIFO on double left click instead of opening it
• new neovim plugin nnn.nvim featuring explorer mode (-F flag)
• explorer mode for nnn.vim
• remove option -w: always place HW cursor on current entry
• accept link name when linking a single target (Create link with any name #1201)
• option -i to show current file information in info bar
• force GNU sed on *BSD and Solaris
• fix preview-tui without -a (Fix preview-tui without -a #1208)
• disable editing file in picker mode (Disable e on picker mode #1183)
• save session in picker mode (Save session after browse() #1190)

Up for grabs

None open at the time.

For anything else please discuss in this thread.

Contribution guideline.

[jcfk]

Any chance you'll end up including some way to remember the hover position within a child directory?

If I'm hovered over dir1/dir2/file1 inside dir2, jump out to dir1, and then back into dir2, I should end up hovered over file1 instead of at the top of dir2.

[jarun]

Sorry, no plans to memorize as it's very use-case specific. Also, it makes nav-to-type mode management extremely complex.

[keiviv]

Nnn is so perfect that I actually had to fanboy-google the author. I very (very) rarely do that - last one I googled was Fabrice Bellard, years ago.

The best todo is to cherish and keep this rare combination of power, simplicity and clear vision. These days it's so rare (sadly) it feels almost magical.

I see 3 areas of possible long-term improvements:

1. Wider OS inclusion via a curses alternative. This is clearly not a priority, but should be considered long-term. More users, more sponsors, worldwide domination.
2. Nvim plugin. While most useful, it can be improved. Sometimes it's empty. sometimes it has own plans. Clicking its window traps. No auto-next on select (as if -J). I use it every day, very grateful to luukvbaal for it, but also very excited to see it on the improvements list. Nvim + nnn is majestic.
3. Archivemount is not a great piece of software. The author even mentions he is not proud of the code. It's in a sense the opposite of nnn - limited, slow and chaotic. Since most usage cases are rather simple (list, add, delete, rewrite), maybe a 7z wrapper would be more practical, performant and clean. It also would allow Windows and non-rooted Termux users to enjoy the full power of nnn (due to fuse they can't atm).

Keep being cool!

[jarun]

Thanks for the compliment!

Regarding your notes:

1. Windows does support curses through PDCurses. I think post let me try dual-boot phase, most users choose a single path - the GUI or the CLI, the former being more in number. Those who pick the GUI are predominantly on Windows. So as long as no one tries nnn with PDCurses we have to understand there's no need for it on Windows.
2. It's new, so it would have its quirks. Please raise defects on the project with clear reproduction steps and we will actively work on them. Auto-proceed on selection is not implemented as it would be an issue when you don't want to select anything and just want to pick the current file on Enter. Maybe we can improve the flow that when there a selection we don't pick the last hovered file. But in any case, it would be confusing and need documentation. @luukvbaal please have a look at the other notes.
3. I didn't understand what you mean by 7z wrapper. You can use 7z independently with nnn without installing archivemount.

[jarun]

Commit 24b71bc takes care auto-proceed and pick on Enter.

@luukvbaal please take a note for nnn.nvim. Note that we still support -J to disable auto-proceed.

[keiviv]

I suggested to increase / ease OS support as I only want more people to enjoy nnn - benefiting both them and you. Some have to use Windows not because they love it. But this is of a low priority - just global plans for the future to make things as easy as possibru if you have time for it.

By 7z wrapper I meant maybe some non-archivemount, alternative way to transparently access archives. Suggested it because I often forget I can't use fuse on Termux without root, and instinctively press m. Also - Windows (fuse is painful there). It is debatable if this a core or plugin functionality, and fully up to your vision.

P.S. I just want to make it clear that I highly respect @luukvbaal, and that those minor imperfections I mentioned in no way preventing me and everyone else from using and loving his hard work every day. I'm simply glad it will get more awesome.

[jarun]

On Linux you can install p7zip-full, override NNN_ARCHIVE to include more extensions and list, extract or open them on Enter independently of archivemount (it's an optional dependency).

[keiviv]

Yes, that's what I use. But a transparent in-nnn access via 7z (or other) would be way cooler, I think. But it's up to you, and of course is not essential or priority.

I'm trying my best, man... You shouldn't have written such a perfect piece of software that it's so hard to add something to a todo list. No one to blame here but you 😄.

[jarun]

But a transparent in-nnn access via 7z (or other) would be way cooler

You mean you want to open it by default using 7z? That's not possible because many archive formats are not supported by 7z also e.g. rar. We wouldn't hard-code more utilities for archive handling. Already we do that for bsdtar, tar and patool which are more of less generic.

[keiviv]

7z supports rar reading (edited). Its format support is extremely wide. Igor really made a swiss knife of archiving - I doubt anyone can name a practically used format it does not support - that's why I suggested it as an all-in-one optional archive handler. Thought - if it's just one single entry point & logic for everything - why not.

It shares the same ideology as nnn - small & powerful.

Not insisting though, just something for you to consider for later.

[jarun]

1. I don't really have the time to explore another utility. atool uses 7z internally anyway.
2. 7z cannot auto-detect archives by extension (tried rar and tgz) at least when creating:

1 ~/GitHub/nnn$ 7z a archive.tgz CHANGELOG Makefile

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (806E9),ASM,AES-NI)

Scanning the drive:
2 files, 53413 bytes (53 KiB)

Creating archive: archive.tgz

Items to compress: 2



System ERROR:
E_INVALIDARG
1 ~/GitHub/nnn$ 7z a archive.rar CHANGELOG Makefile

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (806E9),ASM,AES-NI)



System ERROR:
E_NOTIMPL

[keiviv]

Yep, rar is read-only, I've edited right after posting. But firstly rar is closed source commercial (and rather rare usage-wise last ~10 years due to 7z rise), plus reading is better than nothing. It's basically one single edge case.

Not pushing it, just trying to evaluate pro and contra. Well, just keep it in the back of your head then, maybe one day you'd want it.

[luukvbaal]

@keiviv

Sometimes it's empty. sometimes it has own plans. Clicking its window traps.

Can you explain what you mean by this if the issues are still present and/or open issues on nnn.nvim? First issue might have been fixed by luukvbaal/nnn.nvim#6?

[keiviv]

@luukvbaal - sometimes (rarely) the window is empty, need to close & re-open. I did not submit the issue as I cannot find any logical correlations yet (due to the rarity), and was afraid to waste your time. Same for the 2nd. I'll submit if I find more useful info for you.

The clicking issue you can ignore if you are busy - as most vim people don't usually even use mouse. But on Termux it's sometimes easier to touch. Most floating windows plugins (e.g. Telescope etc) process touches correctly, but nnn traps the cursor (as it's a terminal) - and you cannot exit unless :q. When deep into work I sometimes forget that.

None of those are critical, and I love you. Nvim + nnn + your plugin is a dream combo. I was simply glad to see it on this list - as opposed to forgotten. My remarks were clumsy, and came out way more snarky than it was in my head. Even added a P.S. in the next post when I re-read it and blushed.

Just do your things. You guys know what you are doing.

[luukvbaal]

Alright, thanks for the kind words. I'm not sure about mouse behavior either, although pressing i (to go back to insert mode) should be sufficient to get out of the trapped state. There is no need to :q.

According :h terminal-input mouse events are supposed to be forwarded to terminal buffers:

Mouse input has the following behavior:

- If the program has enabled mouse events, the corresponding events will be
  forwarded to the program.
- If mouse events are disabled (the default), terminal focus will be lost and
  the event will be processed as in a normal buffer.
- If another window is clicked, terminal focus will be lost and nvim will jump
  to the clicked window
- If the mouse wheel is used while the mouse is positioned in another window,
  the terminal wont lose focus and the hovered window will be scrolled.

I'm positive this worked properly at one point in nnn.nvim for NnnPicker but not for NnnExplorer. I assumed at the time that this had to do with the floating window but according to the docs it's supposed to forward mouse events for all terminal buffers.

The thing is that I can't find any commit where mouse events are being forwarded now, has this ever worked properly for anyone in nnn.vim @mcchrish? For me it doesn't work in any terminal buffer anymore even without any plugin, i.e. :e term://nnn doesn't work despite mouse=a being set..

I agree it isn't the most important but if is supposed to work according the the docs I would like to have it work.

[keiviv]

Wrote :q just as I was quickly testing it before posting - and closed without selecting. Posted the wrong brain register 😄. Yes, i to restore the keys functionality. But you've got the gist - an extra quirk to remember. Sometimes when deep into work you press keys in auto-pilot and forget it.

But this is not important, only if you are in a Sherlock Holmes mood.

[luukvbaal]

It turns out running tmux inside the terminal buffers makes mouse support working on my setup lol. So changing nnn cmd override to tmux new-session nnn lets you interact with nnn with the mouse and prevents the "trap" as well.

[luukvbaal]

Wonder why this is necessary, I usually use st but the same behavior is present on xterm and kitty.

[keiviv]

Err. I am running tmux though.
Added: Do you have termux + tmux to test?
Added: If not - install from Github or F-Droid, the Store version exists, but is discontinued.

[luukvbaal]

Running neovim inside tmux makes no difference for me, you need to actually set the cmd override for nnn.(n)vim to tmux new-session nnn.

I suppose this results in some sort of nested tmux session if you're already running tmux outside of nnn.(n)vim but it's what works (for me) 🤷🏻‍♂️

Edit: haven't tested termux.

[keiviv]

Ah. Anyway I already feel guilty for bothering you. Just maybe put it into a low priority and do your things, this is not really important.

[N-R-K]

It turns out running tmux inside the terminal buffers makes mouse support working on my setup lol.

Same here on vim. sfeed_curses works fine however, don't have any other interactive terminal apps to test on. So I am assuming this is an nnn issue.

[luukvbaal]

I'm not sure, I see the same behavior with htop.
:e term://htop no mousef forwarding, :e term://tmux -> htop mouse forwarding.

[N-R-K]

I'm not sure, I see the same behavior with htop.

Ahh, forgot about htop. Yes same here. I guess tmux and sfeed_curses are "signaling mouse events" while nnn and htop aren't?

[luukvbaal]

I'm not sure why one terminal application works and the other doesn't. Imo this should be agnostic the the terminal applications and instead just work if mouse events work outside of the vim terminal if events are properly forward as claimed by the docs. No idea though.

[N-R-K]

Looked into the sfeed_curses source. This patch works:

diff --git a/src/nnn.c b/src/nnn.c
index 8499489..ac1b802 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -2079,6 +2079,8 @@ static bool initcurses(void *oldmask)
 	//intrflush(stdscr, FALSE);
 	keypad(stdscr, TRUE);
 #ifndef NOMOUSE
+	printf("\x1b[?1000h\n"); /* xterm X10 mouse mode */
+	printf("\x1b[?1006h\n"); /* extended SGR mouse mode */
 #if NCURSES_MOUSE_VERSION <= 1
 	mousemask(BUTTON1_PRESSED | BUTTON1_DOUBLE_CLICKED | BUTTON2_PRESSED | BUTTON3_PRESSED,
 		  (mmask_t *)oldmask);

I have no clue how it works, or what it's doing though 😄

P.S tmux seems to be doing something similar.
https://github.com/tmux/tmux/blob/ee9885a40ced1fd34fe2eed879a40975a0691ac8/tty.c#L770-L773

[62832]

That might be it. I do have kdialog installed on this machine, but I have also just tried it on another machine without the kdialog package installed at all and only the fake script from above. On that machine, it still opens nnn just as I'd want it to, but my main one must have an issue with the env var the way I have set it.

[luukvbaal]

Like I said, chromium will not use your custom kdialog script if it finds the kdialog package proper earlier in your PATH. Doubt the issue is the env var, just try it with XDG_CURRENT_DESKTOP=KDE chromium/chrome/brave.

[62832]

GOT IT. It seems like also having GTK_USE_PORTAL=1 exported was causing conflicts with that. Removing that var and uninstalling any desktop portal package I had fixed it when running Brave as just suggested.

[luukvbaal]

I see, but are you now actually able to use nnn as the picker for chromium? Doesn't seem to work for me.

[62832]

Well, yes in the sense that nnn now opens on my main machine too with the right var exported. Of course, actually using the picker functionality like this isn't quite going to work, so maybe the script could do with some more fleshing out to use the picker functionality properly (unless this simply wouldn't work at all).

[luukvbaal]

Well like @N-R-K said, the python script you linked just writes to stdout which is what nnn -p - does. So if the original script works, I'm not sure why this doesn't.

[jarun]

Guys, when you are done, probably update the Wiki with the steps.

[N-R-K]

Well like @N-R-K said, the python script you linked just writes to stdout which is what nnn -p - does. So if the original script works, I'm not sure why this doesn't.

Some weird shenanigan is going on. The following works for me.

#!/bin/sh
pick() {
	st -e nnn -p /tmp/pick
	cat /tmp/pick
}
pick

[N-R-K]

I guess you need to write to stdout of the script itself and somehow invoking st breaks that?

This also works btw:

#!/bin/sh

tmp="${TMPDIR:-/tmp}/nnn_pick"
pick() {
	st -e nnn -p "$tmp"
}
pick && cat "$tmp"

[62832]

Perfect. Uploading files works just fine. Now it might be worth ironing out / making sense of the other direction (Save As...) in this way.

[luukvbaal]

I checked /proc/$$/fd of the kdialog script which contains a pipe for stdout. This works as well:

#!/bin/sh
st nnn -p /proc/$$/fd/1

It writes to the pipe that is used by chromium I presume.

Indeed some parts of the original script you posted are required to distinguish between upload and save as, I could check it out tomorrow.

[luukvbaal]

This works for upload, save to folder with filename from chromium(select and quit) and save to new file created in nnn(select with enter or select and quit).

#!/bin/sh
while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --*) shift ;;
    *) break ;;
esac done
file="${file##/*/}"
st sh -c "nnn -p - | awk '{print system(\"[ -d \" \$0 \" ]\") ? \$0: \$0\"/$file\"}' > /proc/$$/fd/1"

Added some sh -c and quote shenanigans along the way, I'll check if any of those can be avoided tomorrow and add it to the wiki.

Edit: used st -c chromiumdialog to make it floating in my window manager🔥

Unfortunately this broke my current solution for chromium "show in folder" with nnn. I guess XDG_CURRENT_DESKTOP=KDE makes chromium look for some KDE program for "show in folder".

[jarun]

@luukvbaal please add the details to wiki. ;) also does this work with my browser, firefox? ;)

[N-R-K]

@luukvbaal please add the details to wiki. ;) also does this work with my browser, firefox? ;)

Afaik firefox needs some other var GTK_USE_PORTAL=1 maybe, you might also need to mess around in about:config with some "portal" related settings. Haven't tried it though.

[jarun]

Thanks!

[luukvbaal]

Added instructions here. I'm not sure how to adapt to firefox if possible @jarun.

[luukvbaal]

Also not sure why and how to fix the "Show in folder" button stops using xdg-open for inode/directory which is set to nnn on my system.

Guess we need to know what chromium is trying to open with XDG_CURRENT_DESKTOP=KDE.

[jarun]

Thank you! Don't worry about Firefox. Someone willing to try it out will show up someday. 👍

[N-R-K]

I can't figure out what's going on with firefox either. Which is unfortunate, because I'm using it as my primary browser where this feature would be pretty useful. If I do figure it out, I'll update the wiki and give a ping.

[luukvbaal]

It seems like XDG_CURRENT_DESKTOP=KDE completely disables xdg-open on chromium. Not only "Show in folder" stops working but also just trying to open any downloaded file 😞

Tried looking through chromium source but haven't found yet what it's trying to do instead...

[luukvbaal]

The issue lies in xdg-open itself not chromium, which makes more sense.

Creating a xdg-open wrapper that unsets XDG_CURRENT_DESKTOP restores xdg-open functionality on my system.

Edit: added instructions here.

[62832]

It seems like XDG_CURRENT_DESKTOP=KDE completely disables xdg-open on chromium. Not only "Show in folder" stops working but also just trying to open any downloaded file disappointed

Tried looking through chromium source but haven't found yet what it's trying to do instead...

Strangely enough, even opening any file through nnn itself with that var exported is completely broken since xdg-open just refuses to run then. Unless I have some other package interfering with it or I'm missing some other package, that wrapper script is probably gonna be the way to go.

[62832]

Well now that the wrapper scripts are set up and everything is going according to plan, the only minor annoyance is that the nnn picker always runs twice on first use every time the browser starts. I imagine it could get annoying after a little bit and I'm not really experienced enough to know how to suppress that, but it's not really a huge issue for the moment.

[luukvbaal]

Yep XDG_CURRENT_DESKTOP=KDE borks xdg-open if you're not actually in a KDE environment (just run XDG_CURRENT_DESKTOP=KDE xdg-open <file>.

The issue to me seems that xdg-open has no fall back for XDG_CURRENT_DESKTOP=KDE. See for example KDE vs Gnome in xdg-open:

open_kde()
{
    if [ -n "${KDE_SESSION_VERSION}" ]; then
      case "${KDE_SESSION_VERSION}" in
        4)
          kde-open "$1"
        ;;
        5)
          kde-open${KDE_SESSION_VERSION} "$1"
        ;;
      esac
    else
        kfmclient exec "$1"
        kfmclient_fix_exit_code $?
    fi

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

open_gnome3()
{
    if gio help open 2>/dev/null 1>&2; then
        gio open "$1"
    elif gvfs-open --help 2>/dev/null 1>&2; then
        gvfs-open "$1"
    else
        open_generic "$1"
    fi

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

The gnome case has an open_generic fallback which the KDE case lacks.

Perhaps using a different XDG_DESKTOP_SESSION will allow to use one less wrapper.

[luukvbaal]

the only minor annoyance is that the nnn picker always runs twice on first use every time the browser starts.

Hmm that is annoying, I see it too.

[luukvbaal]

Chromium asks for the version of kdialog the first time it is run. Changing the opt parser to

while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --version) printf ""; exit ;;
    --*) shift ;;
    *) break ;;
esac done

fixes the issue.

[jarun]

Rolled at #1219.