@apjana since I have you here. (Feel free to gracefully decline to answer any of the following.) May I ask why are you not trying to leverage the assortment of useful tools you wrote with sizeable following to be some kind of side income? I didn't miss the paypal link on every repo, but I don't think that would make much without being a recurring payment and a little bit of blog posting.
This was partly inspired by the 'to spend more time with his kid than at a computer' quote.
a bit off topic: do you have a rough idea about the number of actual users, other than github stars?
I am not trying to doxx you or anything :D, just thinking about the dynamics of open source and my own inspirations.
-----
Disclaimer: I don't any experience with what I am talking about.
> May I ask why are you not trying to leverage the assortment of useful tools you wrote with sizeable following to be some kind of side income?
I started contributing to open source because I learn a lot from it since my graduation days. I think of it as a payback to the community. Having said that - I do appreciate users donating now and then. :)
> This was partly inspired by the 'to spend more time with his kid than at a computer' quote.
My regular job is a demanding one. So I have to work smart to save time for my kid and family. Some of the utilities were written to help with that.
> Do you have a rough idea about the number of actual users, other than github stars?
Not really. But I know for sure even some orgs use some of my utilities.
This is very exciting and planning to give it a try to see if it can finally replace my usage of midnight commander. I appreciate the clean aesthetics.
Please don't hide your feature list under a toggle though! Put it all the way at the top - I nearly missed it.
Thank you for the appreciation! The full feature list is not hidden, it's below because it got way too long (who would have thought?). The toggled one is a quick peek into some of the cool things users can do with nnn.
Don't know what the situation is like today, but not so long ago not all architectures supported floating point numbers. Math operations were emulated in software libraries, which was slow and buggy.
I never understood terminal file managers... If I want to find a file, I use find or fzf. If I want to list files in a directory, I can use tree or ls. If I want to move files around, cp and mv work great.
If I want something more rich or discoverable, I'll just move to a GUI, which handles this much better.
Try to think of it as an endless ls-cd loop with tons of automated functionality few keypresses away. Also, please try the type-to-nav mode in nnn.
Also, find/fzf etc. are useful as long as you are not on a slow disk and a mid-range Android device/the Pi. If you are saying you are OK with scanning the whole filesystem every time you are looking for something that can be anywhere under /, I simply don't prefer that.
That'll print the list of files even in a populated directory like /usr/bin and leave me at the prompt with the last few files listed above. As soon as you want the list of files not to go away so you can control/manage/examine them, you are talking of a file manager.
Find has a pretty poor API in my opinion. Replacing it with fd is a simply improvement similar to ripgrep over grep.
Separately, I have a bunch of keybindings to load sets of files into fzf for easy access. Things like modified files, files changed in current branch, branches modified in the past six weeks. All of these have make working for a large code base much easier for me with little downside except have to piece them together on a new machine.
I found switching to fd challenging. fd makes some of the options easy. But find and fd are not syntactically the same. I guess I didn't spend enough time with it.
No, you are probably right. My main usage of find is `find ./ -name "blah"` which with fd is simply `fd blah`. If you are doing more complex finds then it may very well not be a good replacement for all find usage.
I just checked both fd and ripgrep and they both seem like wonderful tools. I've been using a very long and slow bash script for what ripgrep to make grep -R avoid my node_modules directory.
Being realtively new to Linux both these commands will be super helpful to me. Are there any other command line tools you will recommend?
For other things like files changed in current branch I've just kludged together aliases:
branch_files='git log --decorate --pretty=oneline --abbrev-commit --name-only --no-merges --first-parent main..HEAD | fpp'
(fpp extracts file paths from output)
If you use zsh it can also helpful to setup suffix aliases so just the filename is bound to an application. For instance `alias -s {rb,erb,rake,css,js}=vim`
I like using terminal file managers for quickly traversing many nested directories, where I'm not sure where I want to go. I can use it to browse around and hjkl is familiar as a vim user.
With ranger[0], I can even use it as an alternative to cd, which is often the most convenient (I usually want a terminal in the last directory I browsed to, not the place where I opened the file manager[1]).
I hope to find a way to use nnn similarly, but it (like ranger) doesn't seem to support this out of the box.
> but it (like ranger) doesn't seem to support this out of the box
No utility can support cd-on-quit out of the box because a spawned process can't send the $PWD to the parent directly when it quits. It needs tweaks in your shell's rc file. nnn also needs the same instrumentation.
I use them because they fit better in my workflow. I use a tiling WM and vim bindings everywhere I can because keyboards hurt my hands less than mice. I use them just for discovery, if I know what I want mv / cp / find are better. tree doesn't work so well if you have a sub-directory with hundreds of object files, etc.
In my life I’ve occasionally used emacs dired-mode[0] to do medium-sized file operations; more than just 1 or 2 files, but not worth building a script w heuristics.
Hasn’t been a problem for me for years. It seems to me that often this argument is based (directly or indirectly) from conditions 20 or more years ago. I think Emacs itself hasn’t changed much (it’s gotten better, but not fundamentally different), but the supporting environments (read: hardware) easily make for a usable experience. There are better poster children for bloat these days.
I suppose I've not tried it in any sort of extreme scenario, but it's not clear to me what dired would be slow at. Functions like copy-file are implemented in C.
They can be handy if you're in the middle of something else, and you need one without distraction.
I don't personally use them, but I live in emacs for many hours a day so I do use its integrated directory-manager (dired) to perform simple operations.
My main use nowadays is to select files. i.e. I have a folder with many files, and I need to cp or mv some of them elsewhere. If it's more than a handful tab completing them is a chore, so I run "mc".
A gui doesn't help, because usually I'm on a remote server somewhere (using SSH).
Take a look at Ranger. Ranger gives you the ability to do things like bulk edit files within a vim editor. Try doing this on the cli with the same efficiency and speed. This is where a term file manager really begins to shine...
That doesn't really help - something like "POSIX-compliant, follows Linux kernel coding style" doesn't really indicate what it's useful for.
My question isn't snark. It's more like "what is the usecase and what advantages does it have over standard terminal workflows?"
FWIW:
My main file manipulations I need to do are within vim when working on a project. I typically use nerdtree for this, but having a project that's consistent in my environment would be good.
I do other manipulations using standard tools like ls/rm/etc. what advantages does this have over those ?
Thanks for voicing what I've been feeling. I've just never got any kind of file browser in the terminal. As you said, there are better tools for browsing that require less investment in a partiuclar way of thinking.
Why do I want to invest in the particular way of thinking required to use GUI file browsers when I have a plethora of options in the terminal? (ranger, lf, mc, and nnn being the better know ones, but there are others too)
A note for anyone who is thinking of switching from ranger, to customize key bindings you need to recompile the application [0]. The developer is not interested in maintaining custom keybinding support. For more insight into the reasoning behind the current keybindings see this issue thread [1].
Also mentioned in this thread, lf a ranger clone written in go [2].
The funny thing about nnn is that the maintainer is absurdly responsive to the point that whenever I didn't like something, rather than configuring it, I would complain and after some consensus from fellow complainers it would get changed in a commit which I immediately enjoyed since I use nnn-git from the AUR.
That's correct, we don't tend to add dispensable features without multiple users asking for it. Of course, features you demand would mean the world to you, but from where I stand, a feature bloat is the last thing in my mind. And the funny thing is, some users find it reasonable.
I don't think I ever asked for features actually; it was usually keyboard shortcut tweaks and other minor changes like that. Although obviously not really configurable keys, I felt like it was an interesting experience.
OK, then let me tell you a story - if you see the `^` and `v` in the latest release, someone requested for those and I personally found them useful and added those on first request. A week later, someone else asked for a program option to disable those.
If you think maintaining a piece of software like nnn is easy, it's not. You can't make everyone happy.
Yes, that's the stand from the beginning and there are good reasons behind that. If you read the issue thread, we did spend a good amount of time discussing those keybinds and most users find them reasonable. Speaking of compiling, the only mandatory library dependency is ncurses and the users don't consider it a significant problem. For example, Arch Linux users install most software from source using formulas and so do Homebrew users. So the tools to build are already present on the system.
For some reason I found it too clunky and slow on a machine that runs other electron apps just fine. I was also looking for something simple as I was not well versed in git at the time, and it was a bit bloated for me.
Try ranger, even less orthodox, to get a MacOS like navigation into your directories from left to right (aka Miller columns), but with VI key bindings and lots of extra features:
I just tried using nnn and found it to work reasonable well. However, I could not figure out how to change the default editor to open vim in the same terminal.
Then I realized that I can accomplish this task already by running
vim .
It seems almost identical to nnn with the restriction that everything is opened vim.
This was partly inspired by the 'to spend more time with his kid than at a computer' quote.
a bit off topic: do you have a rough idea about the number of actual users, other than github stars?
I am not trying to doxx you or anything :D, just thinking about the dynamics of open source and my own inspirations. ----- Disclaimer: I don't any experience with what I am talking about.