Rolled from #110.
N (1 <= N <= 4) to switch to context NNNN_OPENER to specify file openerNNN_NOTE and keybind for quick notesDISABLE_FILE_OPEN_ON_NAV to NNN_RESTRICT_NAV_OPENmimeopen)$EDITOR, $PAGER and $SHELLfore file removalNNN_USE_EDITOR is setl keys)nnn as a file picker within vimnlay (no more used by nnn)$TMPDIR if availablepatoolget_coolsize() (thanks @arsv)NNN_NOWAIT to unblock nnn (DE specific)xdg-open on Linux and open(1) on OS X as desktop openernlayvlock as default terminal screensavernlay - a shell script for actions like open desktop search utility, run screensaverlessQ to quit to current dir (needs external shell integration)^Q to quit (even from filter mode)- to jump to last directory~ (HOME) at chdir prompt~ (feature removed)lstat() details)NNN_COPIER)Up and Down at the first and last entriesAnything else which would add value (please discuss in this thread)
@jarun what do you think of putting the vim plugin to its own repo? It can make installation easier for plugin manager.
@mcchrish I would be more than happy! Would you be kind enough to maintain it? (I don't see too many changes coming).
@jarun not well-versed with vimscript but if no one hasn't done it yet I'll take a look.
@jarun https://github.com/mcchrish/nnn.vim
So for vim-plug just:
Plug 'mcchrish/nnn.vim'
Thanks for the awesome tool!
Awesome! I am retiring the plugin from my project and linking to yours. ;)
Many thanks!
@jarun Hi!
What do you think about having a configuration file?
like $HOME/.config/nnn/nnn.conf
@gabyshev no plans as of now. nnn tries to get the settings from env variables instead of reading a file from the disk. Also, there are not too many config points designed for nnn.
Hi! I was using the latest version, and I'd like to suggest that every time copy/move/list selection is called, nnn read the selected files from ~/.nnncp. Consider this workflow:
It works just like that even now. Here's what I tried (with lastest master):
^K.P to paste the fileThe list selection works differently though. Listing is purely a local copy for the specific instance till you write the selection to .nnncp using the last ^Y. Listing is for the user to know which files (s)he has added to the selection list so far.
Nice! Indeed, it works. What confused me was this different behaviour of list selection (I use it to check which files are being changed). Anyhow, thanks for your latest additions into nnn.
No problem!
What about having env var for dir color ?
I mean, if you already have at least one env var why don't have 10 or more ?
Maybe I don't see a difference having 1, 5, 10 or 20 but there's one...
Anyway, default blue doesn't work for me, kinda silly to look at man each time I start nnn to see the arg for it and then the number for let's say red.
@kajzersoze how about using an alias? I do the same.
@jarun didn't occur to me for some reason, good idea :)
patching it is also not a bad idea, I guess what I need is in this line :
https://github.com/jarun/nnn/blob/master/src/nnn.c#L3627
Okay, thanks.
No problem!
First off congrats for this project, I've been test-driving it for the past few hours and looks pretty slick! Coming from graphical file managers (mainly Nautilus), the only thing that seems less efficient and hard to get used to so far is the copy/move/delete actions. Perhaps it's "just" the power of habit but I'd love to be able to have the same UX if possible, at least for the path selection:
^space selects a single path, just like ^K in nnn. ^ while moving up/down to other entries and press space for those to be added to the selection. The selected entries should be displayed with a different background color instead of having to press a shortcut (y) to see the list.Shift instead of ^ and moving only up or only down selects a consecutive list of entries, without having to press space for each one.For deletion provide two modes:
del) that just moves the selected entries to the recycle bin (or equivalent location in other OS).Shift+del) that actually removes the entries (after a Y/N confirmation dialogue).As for copy and move, I guess I could get used to the different UX - "Copy selection" instead of "Copy and paste" (^C ^V) and "Move selection" instead of "Cut and paste" (^X ^V) - but would be nice to have as well.
Please note that nnn doesn't only cater to desktops.
^spaceselects a single path, just like^Kin nnn
There's a reason a key is kept without ^ and another with it. It's very difficult on handhelds to use a ^ combination. And for people who use the _navigate-as-you-type_ mode ^ is a must.
To select multiple paths...
As an extra handy shortcut...
Same reason as above. Multiple combinations are very difficult to use on smaller form factors.
For deletion provide two modes
We can have this as an enhancement.
Interesting point about handhelds, it didn't occur to me this was a use case and didn't see it mentioned in the design considerations. Though I'm not sure I'm reading
It's very difficult on handhelds to use a ^ combination. And for people who use the navigate-as-you-type mode ^ is a must.
correctly; are you saying it's very difficult on handhelds to use the navigate-as-you-type mode?
didn't see it mentioned in the design considerations
From the introduction - _It runs on Linux, macOS, BSD, Cygwin, Linux subsystem for Windows and Termux._
are you saying it's very difficult on handhelds to use the navigate-as-you-type mode?
yes, and not because of nnn.
Hi, how can I create (symbolic) links for a selection? maybe 's' and 'h' as options in addition to 'f' and 'd' in 'n' prompt?
@lawnowner this is not a very regular use case. Please use scripts.
Would be great if you can share so I can add it to the scripts directory.
@jarun Roger. Already my fm of choice, well-crafted to the detail--all I could think were link creation and percent-progress for copies. I doubt I'll use another fm, although my contribution may take a while. Thanks.
Hello @jarun. Sorry if this has been asked before, but are there any plans for adding some bulk rename support (e.g. the one from ranger)? If not, would this be easy to implement with a script?
vidir is integrated. Please refer to the docs and help.
@jarun Thanks for pointing it out! Somehow missed it in the readme.
@jarun Hello, I have just started using nnn. I had some queries, but most imminent for my workflow is customizing the file-opener. I've not used desktop environment for long, and when I did I didn't know anything about xdg-open and mimeopen. And as long as I've used ranger and then vifm, I've had configuration file to configure programs to launch the file in. I know about ^o but I think I should not write the programs name every time I want to open a file.
So, could you point me to some websites to learn configuring xdg-open?
You don't need to configure. From your DE file manager, right click on a file and set open with.
But I don't use any DE file manager. I've installed ubuntu minimal version without any DE at all. Don't you think it's not a good idea to have to install a program just to configure file opener?
Don't you think it's not a good idea to have to install a program just to configure file opener?
On latest master, we have restored the support for NNN_OPENER yesterday. So you can specify your own opener like mimeopen.
@lawnowner I found a simple way to do it:
^K to select the file^S to run a commandln -s (ncp) (ncp).ln // assuming you have ncp exportedEntersymlink file.ln should be created now.
@jarun Thanks. That's a good solution among other simple ones, such as a pure shell solution, a script solution, or having any other copier program than ncp 'exported' (assuming it is installed on the system). Although it is my preferred fm, I think that nnn should support link creation natively.
The problem is there may be too many cases (while file/dir creation are limited to the same parent dir):
So you see, to really provide a complete solution is not a trivial thing in this case. What do you suggest?
@jarun After making a selection of one or more files/directories and navigating to a destination directory, via the nnn interface, both linking (N/A) and copying/moving (P/V) involve resolving the same cases against duplicates at the destination. Since nnn can copy/move without re-implementing cp/mv utilities, maybe I could suggest treating the linking operation as pseudo-copying. The 'n' prompt could be a good place to interject link creation options, but of course a shortcut like P/V is another option.
involve resolving the same cases against duplicates at the destination
Yes, we use cp. mv, rm here which have their own guards. I didn't want to re-write the logic again.
Now, for multiple file selection, we do not call cp, mv, rm again and again. We call them once. But I don't think we can do that for ln. I think as this is tied to selection and the methodology remains the same, adding a new option is a natural choice. But it also needs a new option. :(
I was also thinking of using lower level APIs for ln to implement in the same workflow as new.
Maybe I am not just so sure yet, which workflow is better. Let me think a bit more.
More issues, for hardlinks do we ask for linkname each time of use .sln and .hln for shard and soft links? What do we do if the *ln file exists?
@lawnowner I think it's better to go the API way instead of calling binaries. Would it be possible for you to raise the PR?
Batch link creation is pushed at commit 8ff56d2c74b14f258a15134cbfb7c8a428ecbeef.
@jarun Thanks for the new feature! I think the project has got sensible design decisions, such as sticking to XDG standards, optionally via intermediaries like mimeopen to provide simplified interfaces, and maintaining a lean and keen binary. Hopefully, it remains so.
Latest master also supports links with same name.
Rolled at #202.
@gsakkis feedback for selected files will soon be in.
Most helpful comment
@jarun Roger. Already my fm of choice, well-crafted to the detail--all I could think were link creation and percent-progress for copies. I doubt I'll use another fm, although my contribution may take a while. Thanks.