Fast nnn file browser v1.6 released | Hacker News Reader

Fast nnn file browser v1.6 released

github.com

95 pointsapjana57 comments

There is this (much older) piece of software that does much of what nnn/noice do, and more:

https://en.wikipedia.org/wiki/Midnight_Commander

Author of nnn here. I have intentionally kept nnn feature -restricted. The idea is to have the stuff one really needs. And the main goal of nnn is seamless desktop environment integration.

Also, please note that the learning curve for the additional features is quite high. E.g. to batch rename, one would rather use Thunar's integrated simple visual batch file rename mode instead.

I believe once the number of shortcuts cross a certain limit, regular users normally abandon the utility out of their comfort zone.

> The idea is to have the stuff one really needs.

One of my main uses for a file browser is to quickly go through a list of files and delete some of them when I clean up a directory. And nnn doesn't even support deletion...

Just for listing files "ls" is still usually the fastest way. Operations on the files is what's cumbersome, e.g. when I try to hit the right files for "rm" with tab completion. When nnn can't help with that its use case is very limited to me.

Understood. I do agree a single software can't fit all use cases. nnn avoids destructive operations like delete. However, one can always spawn a terminal in the current directory using `!` and delete the files from the shell.

> Just for listing files "ls" is still usually the fastest way

Not really. `ls` a dir with 20K files and see the difference with nnn. ;) And then, nnn is more about navigation. Try shortcuts like `-`, `&`, `~` (tilde), `....` and of course the `navigate-as-you-type` mode. Looking for a specific file? Try filter mode with search-as-you-type.

Indeed. When i reach for MC or the like, it is more often than not to deal with gnarly file deletions or transfers.

This because they allow me to pick the individual files i want to deal with without potentially screwing up wildcards or such.

In continuation of my earlier comment, nnn has a copy file path to clipboard action (https://github.com/jarun/nnn#file-copy-move-delete). I believe we can extend it to append multiple filenames which can then be deleted from the spawned shell.

Ideas are welcome! nnn is under active development. ;)

They claim higher performance for nnn than mc. Not sure it’s really needed in most cases though... but nnn could come in handy in edge cases of really large directories, say. BTW their docs say that they avoid div instructions in favour of floating point multiply. Is this still faster on recent CPUs?

I can't be very specific without citing examples. The following APIs may explain what I mean:

https://github.com/jarun/nnn/blob/master/nnn.c#L358

https://github.com/jarun/nnn/blob/master/nnn.c#L1267

https://github.com/jarun/nnn/blob/master/nnn.c#L1617

Most of the functions in nnn are targeted to be high-performance like these.

Hmm. I'm not convinced any of your routines are more "high-performance" than the standard-library, have you benchmarked them?

For example, I don't think your getorder() could possibly be faster than __builtin_ctz(), or even a wrapper around ffs(). You also hardcoded the size of size_t to 32 bits, so it's not more portable than those options.

Edit: I checked, ffs is a tiny branch-free routine in glibc:

  (gdb) disassemble ffs
   Dump of assembler code for function ffsl:
      0x0007e9d0 <+0>:	mov    $0xffffffff,%edx
      0x0007e9d5 <+5>:	bsf    0x4(%esp),%eax
      0x0007e9da <+10>:	cmove  %edx,%eax
      0x0007e9dd <+13>:	add    $0x1,%eax
      0x0007e9e0 <+16>:	ret    
   End of assembler dump.

> __builtin_ctz

avoided it to stay out of compiler-specific stuff. we do have plans to replace getorder() with ffsl().

Perhaps I would be more accurate if I say nnn is faster by design. Movement of data around memory is minimal. No redundant bytes are allocated. We use quicksort and optimize further by pushing non-matches down right away so they never appear in a filter comparison again. And of course, using non-lib custom functions enable using static linkage, having a controlled binary size and removing redundant checks/processing because the limits and borderline cases are known.

  > avoid div instructions in favour of floating point multiply.
  > Is this still faster on recent CPUs?

NB - >>[Taking this question out of context]<< - looks like the answer is "no". From a quick test:

- intel Broadwell: 64-bit integer div is fastest, float div is 69% slower, float mul is 50% slower;

- AMD Ryzen: 64-bit integer div is fastest, float div is 47% slower, float mul is 60% slower;

- ARM11 (Raspberry Zero): 64-bit integer div is fastest, float div is 138% slower, float mul is 159% slower.

quick-and-dirty test used: https://pastebin.com/raw/4XqnuXL5

We don't have the case of integer div. And if you take a look into the coolsize() func we don't re-compute the factor. So it's not very significant.

To get the size of a file we multiply only once with this factor.

What is significant is the while() loop where the iterations increase with the file size. There's no mul or div in it giving the API a reasonable performance benefit.

Have you thought of using COPR[1] to provide builds for Fedora and RHEL? I'm asking because I noticed you provide a RPM only for Fedora 26; Fedora 27 is missing.

[1]: https://copr.fedorainfracloud.org

We use PackageCore which integrates well with Travis CI. Fedora 27 is not added to PackageCore yet.

Does COPR integrate with Travis?

"The missing terminal file browser for X"??? What about ranger?

probably lost in the forest chased by a python... ;)

No Windows version, I'll keep using (shameless plug) my minimal but useful https://github.com/TheJare/jm

Sorry about that. I don't have Windows myself and maintaining a sizable C utility in both *nix and Windows is tricky.

I know, sorry I was so terse, I didn't mean to sound rude. Even my little thing has given me a few headaches in OSX or in Windows' Linux Subsystem (where I think it still does not work, no SIGIO/O_ASYNC), so I feel your pain.

No problem! You can use nnn in the Linux subsystem on Win 10. Some of the users reported it works well.

I guess trying the Ubuntu package via WSL could be an option.

Going to give it a try now, been missing something like this on OS X. Any good alternatives I should try as well?

For a graphical alternative, you might be interested in (my) https://fman.io

I remember Total Commander from Windows back in the day, similar feature set to that?

Yup

Awesome work! Total Commander is the one software that I've never found a good Mac replacement for, and it causes me no end of sadness.

Your approach looks very promising, if still early days. Emailing you further specific feedback, hope you keep working on this and continue on your current path.

Thank you!

Downloaded it and using it now. Thanks!

Just awesome!

I remember trying it a couple months ago, but unfortunately it still seems barely usable (at least to me). Performance is probably the worst of all file managers I have tried in the last couple of years, despite not having many features (e.g. no thumbnail support). Opening /usr/bin (~4000 items) results in more than 10 seconds of not being able to interact with the application, while other file managers manage to show results in something 1 or 2 seconds and being responsive while they populate the view.

You're right, sorry. It's a lot of work and I'm still catching up on basic features. Once they're there, I promise it'll be better.

Fman is proprietary software with no source code available, right?

Yes. For more information please see https://fman.io/blog/why-fman-isnt-open-source/

Thanks, that's useful information.

What do you think about making the source code available to paying customers under a non-Open-Source, no-redistribution license that still allows for studying and adjusting the code to meet integration needs or build for other platforms/library versions? Kinda like Gitlab does with the Enterprise variants.

OS X is well-supported. One of contributors is a OS X-only dev.

Forklift is nice as well

Nice! I gave it a go on MacOS, but managed to segfault it when pressing 'D' on a directory. Can't reproduce :(

Also after quitting 'ls' output is pretty messed up. Seems good overall though.

> managed to segfault it when pressing 'D' on a directory

Very much possible. Though we have tested as much as possible, we are a small team and the latest iteration has undergone substantial changes. I couldn't reproduce it so far. But please raise an issue if you have some details. Something special about the dir name maybe?

> quitting 'ls' output is pretty messed up

nnn does not write to the stderr/stdout once it is in curses mode. Can you share some more details on the steps?

It would be great if you can raise defects on GitHub. nnn is under active development.

> It would be great if you can raise defects on GitHub. nnn is under active development.

Sure, will do!

Many thanks for the reports you submitted!

Looks great. It looks like just what I have always wanted on Ubuntu. Giving it a try!

Thanks for the compliment! Merry Christmas!

Prefer ncdu where you can delete stuff.

ncdu is not a general purpose file browser, it's specifically for deleting large stuff

If we are speaking of ncdu (https://dev.yorhel.nl/ncdu) nnn has a much faster disk usage analyzer mode. And it's dynamic while ncdu is static (by default at least). nnn has a path copier which can copy the file names you would like to delete to clipboard. You can a shell in the same directory using `!` and delete the files.

The decision to avoid potentially destructive operations was a conscious one.

It looks like it is bash dependent

Why do you believe that? It has a section on shell completion for different shells so I don't think that is the intention,

https://github.com/jarun/nnn#shell-completion

https://github.com/jarun/nnn/blob/master/nlay

  # bash 4.0 way to switch to lowercase
  ext="${ext,,}"

Ahh OK! nlay is not an essential part of nnn anymore. It's only invoked if you use the locker or invoke desktop search utility. We retained those two to keep the utilities customizable. Are you using any of these two?

Also, `nlay` is editable and you can customize it anytime.

Thanks for explaining.

The documentation is very poor. Avoid.

We have up-to-date comprehensive README and man page with examples.

If that's not sufficient, please help us make it better. What's missing?

There is NO intro or general overview in the wiki for exemple. Id love to know what this is befors I try and install it.

You might just have missed this - https://github.com/jarun/nnn#nnn

It is a file manager; not something that would require wiki pages to explain what it does. man pages are sufficient in this regard to look at finer details.

For a moment i was expecting Neural Network (NN) from the title. Along the line that NN was used to pre-load directory structures, NN in search results ordering etc.

Reply on news.ycombinator.com