ToDo list

[jarun]

Rolled from #935.

Cooking

• a patch management model for approved patches
• multi-threaded disk usage calculation using pthreads and FTS
• dynamic view update when calculating disk usage
• Bksp/Del at empty filter prompt to refresh dir
• Try to create new context with Shift-TAB, else reverse cycle
• Alt+Esc to quit context from filter prompt
• fix zombies left behind after running plugins (nnn leaves zombies while running plugins #999)
• named persistent sessions (Use one instance for nnn or remember nnn paths mcchrish/nnn.vim#43)
• consider nanosecond resolution when sorting by time (Include milliseconds when sorting by time #978)
• check external selection in 'c'urrent / 's'el prompt (Populating selection with x2sel plugin #976)
• show number of files selected in local selection buffer, if any
• nnn & picker plugin (e.g. fzopen) sync (Weird behavior with fzopen plugin mcchrish/nnn.vim#82)
• make batch rename interactive (Swapping names when batch renaming files deletes one of the files #971)
• cached uid/gid for performance improvement
• fixes for nnn with netbsd-curses, musl-fts, musl (nnn + netbsd-curses + musl libc #998)
• script to statically compile nnn with musl gcc on Ubuntu
• restore hovered file when plugin is chosen from plugin dir
• support QuickLook on WSL in preview-tui (Get the selected file for live preview to work with a MS Window previewer #959)
• toggle preview-tui with the same custom plugin key
• smoother preview toggling in preview-tui (preview-tui: reformat toggle #966)
• listen_on should be set in kitty.conf for preview-tui (preview-tui: error to foreground #970)
• minimal bat style in preview-tui, honors $BAT_STYLE
• plugin preview-tui-ext supersedes preview-tui (Preview-tui-ext to preview-tui #1033)
• plugin fzcd can now fuzzy search multiple directories
• plugin imgview supersedes imgthumb and vidthumb
• plugin umounttree: unmount remote mntpoint from within
• plugin xdgdefault: set the default app for hovered file type
• plugin fzplug: fuzzy find, preview and run other plugins
• plugin cmusq: queue/play music in cmus
• plugin mocplay renamed to mocq
• plugin cleanfilename renamed to fixname
• go to last dir on ~ (HOME) or ` (ROOT) key repeat
• ambiguous key ^Space to select/clear range dropped (nnn + netbsd-curses + musl libc #998)
• user wiki page for Themes
• show selection mark (+) in reverse bold for improved visibility
• reverse block replaces > to mark hovered entry in detail mode
• make option O_CKBOARD removed
• make option O_NOLOC renamed to O_NOLC
• ignore O_NOLC if O_ICONS or O_NERD is specified (icon not set  #1026)
• unicode arrow indicators if O_ICONS or O_NERD is specified
• make option NOX11: disable notis, sel-clipboard sync, xterm title
• retain filter in nav-to-type mode after file open
• fix no files picked with NNN_TMPFILE exported and q to quit
• disable xterm title setting in picker mode (picker mode broken #974)

Up for grabs

• notcurses UI backend (notcurses ui backend #1014) [@KlzXS]
• a light colorscheme with NNN_FCOLORS (Default light colorscheme #937)
• update only current context data when saving session (Storable contexts as the missing link halfway between bookmarks and sessions? #837)
• generate static binary for arm, aarch with releases using CI (arm and aarch releases with statically linked dependencies #623)
• support applying filter by key (like bookmarks/plugins)
• open new terminal window in spawned shell directory (Spawned shell (!) with kitty (--cwd=current) #759)

For anything else please discuss in this thread.

Contribution guideline.

[mizlan]

predefined filters like bookmarks

I've read a past thread but am still confused as to what this means.

[jarun]

Updated now. Basically filter keys to apply a filter at the start of the program. However, I don't see much benefit.
See if the multi-threaded du interests you.

However, I would like the nnn.vim plugin enhancement to support sessions first.

[jarun]

@Kabouik can you please audit nuke in the lines of #935 (comment)?

It would be good to have that done before the next release.

[jarun]

Leave it. I took a look, it's more or less clean.

[jarun]

@CodeforEvolution does Haiku have libpthread? Planning to implement threaded disk usage calculator.

[CodeforEvolution]

@jarun Hello, and I apologize for the recent silence. While Haiku does have a pthread implementation, you'll need to make sure that you link against a library called "libroot". If the build system requires the availability of libpthread, Haiku at least has a "fake" libpthread library file to satisfy that.

[jarun]

Can you please do the necessary modification to Makefile for this change to work: 284a3c4#diff-94e6e1efb3367ceccb57baea06ea5c8ab89faaa9d720ee5e599039710dfcae49R127

[jarun]

Note that we will also need fts.

[CodeforEvolution]

Sure thing! And yes, it looks like we have fts. :)

[jarun]

Cool! This is very important for the next release.

[CodeforEvolution]

@jarun Well, better yet, I can confirm that no additional changes are required! I was able to successfully build the latest commit of nnn and run the test you posted in the commit message.

[jarun]

Just awesome!!! 👍

[jarun]

@luukvbaal are we generating thumbnails for preview-tui* in the same dir within .thumbs?

[luukvbaal]

Not sure what .thumbs is but no. Thumbnails go to $TMPDIR/nnn/previews by default and a suggestion to set $NNN_PREVIEWDIR to $XDG_CACHE_HOME/nnn/previews is present in the docs.

[signed-log]

Hello,
I can make a multi-arch docker container to build the arm images if needed

[jarun]

@luukvbaal

Not sure what .thumbs is but no.

Thanks for confirming! Yes, I confirmed it's not from our previewers.

@Stig124

I can make a multi-arch docker container to build the arm images if needed

@KlzXS @luukvbaal @0xACE what do you guys say?

[0xACE]

@Stig124

I can make a multi-arch docker container to build the arm images if needed

@KlzXS @luukvbaal @0xACE what do you guys say?

Not sure what to say about it. Do as you please...

[KlzXS]

If it can be nicely integrated into your release workflow and produces a useable build, sure.

Do we have someone with these architectures? All I have that is not x86 is a pi zero.

[jarun]

I have a Pi 4 but can't guarantee I'll be able to test on every release.
However, I think it's a good idea in general if we can auto-generate these. We do have a line item.

I think @Stig124 you can go ahead. Please do the CI integration as well.

[signed-log]

Sure, will do

[KlzXS]

can't guarantee I'll be able to test on every release.

Users will test it out in time. Let's just make sure the first binary we release doesn't have any major issues.

[jarun]

The next release is going to be a massive one with the features that are in.

[0xACE]

One of my ARM Cortex-A73 is running on my personal branch based on 950a8f6 and it has been running fine for 3 years, nor have i experienced any issues exclusive to my arm machines...

[signed-log]

Had time to tinker with the image, it builds just fine, but I'm afraid that it won't go fine in CircleCI, I know so little about how CircleCI works that It will take me a while to figure out how to build it multiarch on CircleCI.

More precisely, run it, as I build the images, the executable is blocked into the image and you need to run the image before having a single possibility of getting the executable out of the image. The only way I can think of is to find a way to run QEMU, but without root access on the host system it is impossible, I'll think about that issue tonight and will see

[signed-log]

Hello,

I thank about that, it will not be possible to build executables on ARM using CircleCI.
But I spoke of that w/my boss, and he can loan me for free a ARM64-based machine that I can configure to respond to webhook so that It will be building the executables for nnn in both ARM64 and ARM32 (because I would have QEMU up and running), what do you think @jarun?

[KlzXS]

The main issue with that becomes whether that machine will be available in the future or not. It would really suck if suddenly the arm builds stopped being built.

[jarun]

Can we use some service other than CircleCi? How about GitHub's own service?

[signed-log]

Can we use some service other than CircleCi? How about GitHub's own service?

Travis seems to build ARM executable just fine, but I don't see any that would build armhf executables

[luukvbaal]

If I replace type bat with ! type bat, then it works correctly.

This makes 0 sense to me. If bat in your PATH, type bat should return 0. If bat is not in your PATH ,! type bat would return zero but then it should fail executing the bat command that follows.

NNN_PREVIEWDIR being empty meaning the environment variable as seen by preview-tui, not an empty directory. That must be what's going on if it's creating the previews in PWD i.e. mkdir -p "$NNN_PREVIEWDIR/${3%/*}". No idea why that would be the case if you're on master and exporting NNN_PREVIEWDIR in your .bashrc, and bash is your default shell.

[Kabouik]

type bat returns bat is /home/user/.cargo/bin/bat on my end, not 0. ! type bat too, but that inverts the condition I guess.

[luukvbaal]

I'm talking about the exit status, we're redirecting the actual return value to /dev/null.

[luukvbaal]

It must not return /home/user/.cargo/bin/bat in your "nnn plugin environment" or else you wouldn't have to invert the condition.

[Kabouik]

I think the issue with NNN_PREVIEWDIR is simply that it doesn't accept the ~/ abbreviation. I got confused by my other nnn environment variables where ~/ works (like plugins, bookmarks).

One issue though is that if you preview images in the preview directory, it will create another subdirectory for that, but then that means it can loop on itself. Wouldn't it be best to prevent preview-tui* from creating previews cache for images viewed inside a sub-folder of $NNN_PREVIEWDIR? I know no one should do that, but I feel it would be safer to keep the script from caching previews for existing cache previews themselves. Excluding the folder would perhaps be enough?

[luukvbaal]

I've come across that situation while developing the plugin yeah but indeed no one should open preview-tui in the cache directory. Not sure if it's worth preventing that, perhaps it is.

[luukvbaal]

Indeed always prefer using $HOME over ~ in shell variables. ~ is not expanded when quoted.

[Kabouik]

I feel it could be useful even if it's weird to preview that folder on purpose. If the preview pane is already opened, then anything hovered will be previewed, meaning one would have to know about that issue in advance before going into the cache folder with nnn to remember that the preview pane should be closed beforehand. Going into that folder is not a rare use case I think, I would expect people to keep an eye on it to monitor its size and delete unnecessary cache.

[Kabouik]

It must not return /home/user/.cargo/bin/bat in your "nnn plugin environment" or else you wouldn't have to invert the condition.

Right, I was just testing the command directly in terminal here, I misunderstood from your message that 0 was the expected result. The above reports in my previous messages are all from executing the full script through nnn though, and adding ! does fix the use of bat on that machine. Can't tell yet if I observe the same on other machines, but I assume I won't since you have no such issue on yours.

[Kabouik]

Indeed always prefer using $HOME over ~ in shell variables. ~ is not expanded when quoted.

Thanks! Yeah I already use $HOME everywhere else in my .bashrc but got spoiled for nnn variables because nnn tends to be flexible: https://github.com/jarun/nnn/wiki/Basic-use-cases#add-bookmarks

Maybe we should edit the wiki to discourage this use, or is there a way to make NNN_PREVIEWDIR equally tolerant to ~/?

[luukvbaal]

Yeah export NNN_BMS="d:$HOME/Documents;u:$HOME/Cam Uploads;D:$HOME/Downloads/" is more appropriate as an environment variable in my opinion. Not sure how @jarun feels about it.

The reason it works for NNN_BMS is because ~ is expanded by nnn itself. There are ways to expand quoted ~ in shell scripts but I don't feel that's appropriate for nnn plugins to do.

[jarun]

Can you summarize the NNN_BMS thing for me?

[luukvbaal]

@Kabouik ran into an issue with preview-tui because they used "~" in NNN_PREVIEWDIR like suggested in the wiki for NNN_BMS. This does not work for shell scripts without manually expanding "~", using "$HOME" instead is more appropriate.

[jarun]

Why can't the script expand ~?

[luukvbaal]

Shells don't expand quoted ~'s.

[luukvbaal]

See e.g. https://stackoverflow.com/questions/40223060/home-vs-for-use-in-bash-scripts

[luukvbaal]

Nothing needs to change, it's just a matter of whether you want to change the wiki to reflect using $HOME over ~ to possibly avoid users running into the same problem.

[jarun]

OK. I was expecting at least double quotes to work. Why can't you specify the unquoted string in a controlled script?

If space is a problem, doesn't the following work?

~/"Arun Pictures"/something

Anyway, the NNN_BMS thing stays.

[jarun]

it's just a matter of whether you want to change the wiki to reflect using $HOME over ~ to possibly avoid users running into the same problem.

@Kabouik mentioned NNN_BMS which is parsed by nnn. It resolves ~ but doesn't understand $HOME. hence the explicit ~ usage in the example. I think @Kabouik is mixing up stuff. The shell limitation is not nnn issue.

[luukvbaal]

$HOME doesn't need to be parsed by nnn as it is expanded by the shell when assigned to a variable.

[luukvbaal]

It's just generally more advised to use $HOME in shell variables as it works in all cases as opposed to ~.

[luukvbaal]

@Kabouik is indeed at fault for using ~ in NNN_PREVIEWDIR although I can understand why he would expect it to work when it does work for NNN_BMS since it is parsed by nnn.

Again, changing the wiki to use $HOME instead of ~ could prevent other users making the same mistake.

[jarun]

OK. Please update. You may have t do it in the man page as well (for NNN_BMS).

[Kabouik]

I think @Kabouik is mixing up stuff. The shell limitation is not nnn issue.

No that's my understanding too now, but yeah initially I was thinking I could use the same syntax in environment variables parsed directly by nnn or by its plugins, since I didn't know about the shell limitation and all those environment variables look similar (NNN_*), which led me to misuse NNN_PREVIEWDIR.

I just find it misleading that the wiki shows ~ abbreviation working for variables parsed directly by nnn whereas it won't for those parsed by scripts, but I don't think every nnn user would be as ignorant as me when it comes to shells. :> I have no strong opinion about whether the wiki should show $HOME to avoid the ambiguity, or if scripts could be made to work with ~ in environment variables, I just feel harmonizing would save mistakes for some users.

[jarun]

That's fine. It's good to be uniform.