3 ms·

This seems pretty cool, but why does the source code have to be contained within a single 4000 line file[0]? I'm fairly ignorant of the design patterns used in

by mereel 7y ago

This seems pretty cool, but why does the source code have to be contained within a single 4000 line file[0]? I'm fairly ignorant of the design patterns used in Linux tool development, but it seems like splitting this into a few more files could make the code a little easier to understand/maintain. [0] https://github.com/jarun/nnn/blob/master/src/nnn.c https://github.com/jarun/nnn/blob/master/src/nnn.c

groovybits 7y ago
I believe the concept of nnn is that all the source code is contained in one file. If you wish to add extensions onto nnn, you can then write a c file and include it in nnn.c
- apjana 7y ago
  Extensions are (mostly) POSIX-compliant shell scripts (though they can be compiled binaries also). I have (kind of) explained in the main thread the reason I never felt the need of re-factoring the code into multiple files.
  - groovybits 7y ago
    Ah, it was shell scripts I was thinking of. For the record, the concept makes since to me. I moved from ranger to nnn a while back, and the performance improvement that nnn provides really shows. Thanks for all the hard work!
    - apjana 7y ago
      Thanks for the compliment! The plugin-based mechanism fits perfectly with the fundamental design to keep the core file manager lean and fast, by delegating repetitive (but not necessarily file manager-specific) tasks to the plugins.
apjana 7y ago
I wish some open source enthusiast offered to contribute in return for the re-factoring you are looking for ;). I am (generally speaking) the lone developer of this project for 2 years. And with ctags and cscope I don't find any problem in developing.
spillybones 7y ago
For comparison, the `ls` in GNU coreutils is a single 5,310 line C file[0], so I think nnn's codebase pretty much par for the course (nnn has much more functionality than ls with 1K fewer lines of code). Splitting into different files makes more sense when you have a bunch of independent subsystems, but nnn is just a file manager. As someone who has dug through nnn's source code enough to track down a bug and propose a fix, I found it to be a pretty easy codebase to work with. [0] https://github.com/coreutils/coreutils/blob/master/src/ls.c https://github.com/coreutils/coreutils/blob/master/src/ls.c

by mereel 7y ago

groovybits 7y ago

I believe the concept of nnn is that all the source code is contained in one file. If you wish to add extensions onto nnn, you can then write a c file and include it in nnn.c

apjana 7y ago
Extensions are (mostly) POSIX-compliant shell scripts (though they can be compiled binaries also). I have (kind of) explained in the main thread the reason I never felt the need of re-factoring the code into multiple files.
- groovybits 7y ago
  Ah, it was shell scripts I was thinking of. For the record, the concept makes since to me. I moved from ranger to nnn a while back, and the performance improvement that nnn provides really shows. Thanks for all the hard work!
  - apjana 7y ago
    Thanks for the compliment! The plugin-based mechanism fits perfectly with the fundamental design to keep the core file manager lean and fast, by delegating repetitive (but not necessarily file manager-specific) tasks to the plugins.

apjana 7y ago

I wish some open source enthusiast offered to contribute in return for the re-factoring you are looking for ;). I am (generally speaking) the lone developer of this project for 2 years. And with ctags and cscope I don't find any problem in developing.

spillybones 7y ago

For comparison, the `ls` in GNU coreutils is a single 5,310 line C file[0], so I think nnn's codebase pretty much par for the course (nnn has much more functionality than ls with 1K fewer lines of code). Splitting into different files makes more sense when you have a bunch of independent subsystems, but nnn is just a file manager. As someone who has dug through nnn's source code enough to track down a bug and propose a fix, I found it to be a pretty easy codebase to work with. [0] https://github.com/coreutils/coreutils/blob/master/src/ls.c https://github.com/coreutils/coreutils/blob/master/src/ls.c