5 ms·

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 https://en.wikiped

by kees99 9y ago

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 https://en.wikipedia.org/wiki/Midnight_Commander

apjana 9y ago
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.
- skrause 9y ago
  > 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.
  - apjana 9y ago
    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.
  - digi_owl 9y ago
    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.
  - apjana 9y ago
    In continuation of my earlier comment, nnn has a copy file path to clipboard action (https://github.com/jarun/nnn#file-copy-move-delete 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. ;)
janekm 9y ago
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?
- apjana 9y ago
  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#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 Most of the functions in nnn are targeted to be high-performance like these.
  - fredericoqq 9y ago
    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.
    - apjana 9y ago
      > __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.

by kees99 9y ago

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 https://en.wikipedia.org/wiki/Midnight_Commander

apjana 9y ago

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.

skrause 9y ago
> 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.
- apjana 9y ago
  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.
- digi_owl 9y ago
  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.
- apjana 9y ago
  In continuation of my earlier comment, nnn has a copy file path to clipboard action (https://github.com/jarun/nnn#file-copy-move-delete 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. ;)

janekm 9y ago

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?

apjana 9y ago
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#L358 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1267 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 https://github.com/jarun/nnn/blob/master/nnn.c#L1617 Most of the functions in nnn are targeted to be high-performance like these.
- fredericoqq 9y ago
  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.
  - apjana 9y ago
    > __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.