Rolled from #329.
.history file moved to nnn config directory$NN at command prompt-a to use file access time throughout the program-c to indicate cli-only opener-f to run filter as command on ^P-o replaces config NNN_RESTRICT_NAV_OPEN-t replaces config NNN_NO_AUTOSELECT-r replaces config NNN_OPS_PROGvidthumb - show video thumbnails in terminalmediainf - show media info (decoupled as a plugin)notes - open a quick notes file/dir in $EDITOR (decoupled as a plugin)dups - list duplicate files in the current directoryoldbigfile - list large files by access timemoclyrics - show lyrics of the track currently playing in MOCuidgid list uid and gid of files in directorymocplay - now detects if a track is playing or notorganize - categorize files and move to respective directoriespastebin - now uses ix.io paste servicefzy-edit - merged into fzy-openviuimg - fix directory viewchecksum - fixed POSIX compliance issuesboom - play music in MOC-w)notes)tar/bsdtar always creating tar archives (and not by suffix)-Snnn pluginsbrowse()Anything else which would add value (please discuss in this thread).
List of completed features and tasks.
Is there any flag that when you quit nnn it'll change to that directory? eg. I'm in home then open nnn I go to deep inside directory and after I quit I want to be in that directory.
@wachd you can do that. Please visit https://github.com/jarun/nnn/wiki/Basic-use-cases#configure-cd-on-quit.
@0xACE I am noticing one issue with resize handling. After a resize (down) of the terminal, the earlier visible part is left printed on the screen. See the image below:
I tested this in xterm.
Can you please check if we can handle this?
I'm having trouble replicating/understanding this.
My interpretation (based on your screenshot):
nnnnnnnnn window if you resize up the terminal window or scroll up.It cannot be reproduced on st (my terminal). I tried xterm and I was only able to get the [1 2 3 4] ~/paths part to be potentially printed if you scroll up at step 4. The same problem could be visible on urxvt. But my best guess is really that xterm and urxvt are handling this incorrectly...
I'm not sure I'm understanding your problem description correctly... I was guessing it had to do how I force print the prompt, but I even reverted the KEY_RESIZE patch and the problem persisted... So I'm not sure KEY_RESIZE is the problem, it really sounds like a xterm / urxvt issue.
Could you help clarify the issue description? Because right now the hardest part is understanding the issue.
Btw I started a stub of the wiki article, but I'm too lazy today to finish it o_O
It cannot be reproduced on st (my terminal). I tried xterm and I was only able to get the [1 2 3 4] ~/paths part to be potentially printed if you scroll up at step 4. The same problem could be visible on urxvt. But my best guess is really that xterm and urxvt are handling this incorrectly...
This is what I see. In my case, as you see in the screenshot the initial files are also shown.
I don't think it's KEY_RESIZE issue. When making the terminal window shorter, nothing from the nnn window should be left printed is what I am expecting.
How about copying files in the background and you din't have to wait until files is finished copying.
@aeroslubis nnn uses cp, mv in the background. I don't have the bandwidth to write better and safer attribute-preserving OS/filesystem independent APIs.
To continue using these utilities and achieve what you are looking for, I will need to fork and detach. So I will never know when it completes without adding another mechanism to open a communication channel with the main nnn process. That's elaborate and I am sure I will have to handle many issues to stabilize all of it. Unfortunately, I can't.
However, I think I understand your experience. That's when I started looking for a light terminal multiplexer and zeroed-in on dvtm (instructions). Now I can continue working in the unused pane. I am also waiting for SSDs to be more commonplace (I use one in my laptop and the wait time is not particularly remarkable). In addition, I also use the advcpmv patch so I know where exactly the process is. (Reference problem: https://www.samuelthomasdavies.com/elevator-waiting-times/)
The SSD way has alleviated most of it though. I hardly wait for long and use dvtm rarely nowadays.
This is what I see. In my case, as you see in the screenshot the initial files are also shown.
I don't think it's KEY_RESIZE issue. When making the terminal window shorter, nothing from the
nnnwindow should be left printed is what I am expecting.
From my previous experience with terminals, iirc: neither xterm nor urxvt behaves "correctly". I just tried less ~/.bashrc and the same problem can be seen in xterm and urxvt but not in st
Do you still want me to research it further? (I concur with your conclusion, KEY_RESIZE doesn't seem to be the problem)
Because by my current best guess it seems like a issue with xterm and urxvt no matter what we do...
How about copying files in the background and you din't have to wait until files is finished copying.
Thanks for reminding me. I have also found it annoying to wait for nnn to regain access after moving huge files across partitions/hard drives. My planned implementation is:
nnn is within a tmux sessions, if nnn isn't within a tmux session it will act like nnn does today, a blocking cp/mv operationcp/mv command runshitting any key(At least this is what my plan is and note that I use advcpmv)
Haha that was a cute read
Do you still want me to research it further?
No, we can live with it.
My planned implementation is
Sounds like a good idea. I don't use tmux myself however we can have it for users having tmux.
Sounds like a good idea. I don't use tmux myself however we can have it for users having tmux.
I should mention though that I won't be implementing it as a script, I'll be doing it within nnn.c, but I guess it shouldn't be hard to implement a script version as well...
The following text is not a problem per se, I'm just mentioning a observation and wondering if you have any opinion on it:
Usually tmux should handle the pane splitting fine, but with nnn tmux doesn't see the folder you are currently browsing in nnn so it spawns new panes in the start-location of nnn. You can try it in dvtm:
cd ~/example && dvtmdvtm session type cd .. to go back a directory, you should be in ~dvtm with Mod-C (which is suppose to open a new shell in the active shells CWD) (Notice it's a capital C)dvtm spawned the shell in ~/example even though it should be ~.Afaik this happens because nnn is deliberately not using chdir() when browsing around various directories.
I don't mind the current implementation, but just wanted to bring it to your attention if you feel something should be done about it. But really this discussion can be ignored, we have sort of discussed it before...
Regd. the 4 points. yes, nnn does not do a chdir() when we change the directory. I think there are advantages and disadvantages both ways. Sometimes I start at home but wander away. And when I quit nnn I want to be home again irrespective of whichever location I visited in nnn.
+1 for adding a Miller Viewmode
The fundamental issue with Miller View is too many redundant disk reads due to reading of subdir contents on opening or minor navigation in parent. On a remote mount this subdir content load will also slow you down.
However, if that's what you are looking for, there are alternatives available already.
The fundamental issue with Miller View is too many redundant disk reads due to reading of subdir contents on opening or minor navigation in parent. On a remote mount this subdir content load will also slow you down.
However, if that's what you are looking for, there are alternatives available already.
I see your point, but a) other file managers have implemented this mode as well while staying performant. And b) this mode can be implemented as an optional mode.
a) other file managers have implemented this mode as well while staying performant.
We don't claim that nnn will be like other file managers. It's about not wasting CPU cycles in redundant reads.
b) this mode can be implemented as an optional mode.
We are not considering this feature in nnn.
+1 for adding a Miller Viewmode
I should mentiong that implementing Miller columns in nnn would greatly complicate the code base. To my best understanding: nnn tries to maintain a simple codebase...
I am considering using the current selection when using a selection based operation. Haven't completed the new workflow yet, but let's see.
@KlzXS @0xACE please review the latest workflow and selection key modifications:
@mcchrish @KlzXS @0xACE please review commit 57d9edfed312a6db9f6f4c1949001c082c0cbb9d.
Correct me if this is the intended behavior but when you use range select and then clear the selection (by double pressing m for example) the selection file doesn't get cleared. Selecting anything in any manner after that clears it properly.
Other than that behaves like described in the commit notes.
I am unable to reproduce this with latest master. Are you trying to describe the following sequence?
1. m
2. j
3. j
4. m
5. m
6. m
With this at step 4 three files are selected. And at step 6 all are cleared. Please share the keypresses in order if I am wrong.
Ahh OK, Please see if this is fixed with commit 951d43eb777c09eaeda0efd8515bbcd3119838a4.
That did it.
Thank you!
Hey, I tried out changes and it works fine, I can live with the changes. Not sure if _new_ users will react though...
Not sure if new users will react though...
Didn't understand this part. Do you mean new users will not notice it or they will find it difficult? I thought they wouldn't notice because now the selection mode is gone.
Thanks for the commit https://github.com/jarun/nnn/commit/57d9edfed312a6db9f6f4c1949001c082c0cbb9d. Makes nnn better than new without a hacronym!
In bash CTRL+S already used for forward-search-history function.
How is it confliting with ^S in nnn? When you are runnign nnn you are not in the shell. Or, am I missing something?
It looks like I faced this issue: (https://unix.stackexchange.com/questions/12107/how-to-unfreeze-after-accidentally-pressing-ctrl-s-in-a-terminal)
You need:
stty start undef
stty stop undef
but this is bothersome. We have to replace ^S with something else. I picked S for select but now I am out of ideas. Suggest a ^ combination.
How about ^K for range selection? We need a ^ combination for nav-as-you-type mode.
It should work I guess. And it's relatively easy to memorize.
Hi, is it even remotely possible that user/group could make it to the detailed view?
I know it's available when using D, but I often need an overview of permissions and using D for everything in a folder quickly gets tiresome, hence I always stop using nnn in favor of ls -laht.
@superDuperCyberTechno I did a draft implementation of this and found that if we use getpwuid() and getgrgid() the memory usage becomes very high because the name strings are obtained by parsing files. So I removed those.
But I understand your problem. Is it OK if the username and group are shown in the status bar (adding it to detailed view leads to a lot of manipulation issues as the number of cols will be affected)? If yes, I can make them show in the status bar for a file using a program flag.
Another option would be to have ls -laht as a plugin. You can issue it whenever you want to see the uid and gid for all files in the list.
A third option would be to show only the ID values i.e., the uid and gid values in the status bar. But most users won't like it because they would ask for the strings. I can show it conditionally under a flag and and you will not have the extra memory usage issue. But if there are large number of uids and gids you won't be able to remember so I don't think it's a good idea.
Is it OK if the username and group are shown in the status bar (adding it to detailed view leads to a lot of manipulation issues as the number of cols will be affected)? If yes, I can make them shiw in the status bar for a file using a program flag.
ranger already does this and my experience is that it doesn't really help with getting an overview of the general permissions as I still need to navigate up and down to compare.
The other option would be to have
ls -lahtas a plugin. You can issue it whenever you want to see the uid and gid for all files in the list.
I think this sounds very reasonable. At least being able to toggle the data is very much appreciated as running ls -laht is basically doing exactly that.
Awesome! Here you go:
#!/usr/bin/env sh
# Description: list uid and gid of files
#
# Shell: POSIX compliant
# Author: Arun Prakash Jana, superDuperCyberTechno
ls -laht | more
read dummy
That's great. Can we add it to the plugins? Do you want me to pull request it?
BTW, why not use less as opposed to more?
Do you want me to pull request it?
Yes, please! Please ensure you add the entry to the plugin table.
why not use less as opposed to more?
Please feel free to use less. In that case, please remove the read dummy line.
Alright. I'll have a PR ready when I get to it.
Related question: Any idea why I can't run any plugins as per Method 1?
Both : and x followed by the plugin key does not do anything. I have installed all plugins and are testing the one we just created. I can only run them manually.
Any idea why I can't run any plugins as per Method 1?
It's still on master. Please wait for the next release.
Not sure if new users will react though...
Didn't understand this part. Do you mean new users will not notice it or they will find it difficult? I thought they wouldn't notice because now the selection mode is gone.
I mean that, maybe new users, will not be able to figure out that you can clear the selection with mm.
But don't worry about it, to be honest it is not a big deal. And I personally like the change... You did a great job applying this patch and I'm happy with it.
I mean that, maybe new users, will not be able to figure out that you can clear the selection with
mm.
We'll have this documented in Wiki. I haven't updated it yet on selection as I'm still testing these changes. probably I'll hold off that update till the next release so current users of released version have the correct info.
@superDuperCyberTechno I have added the plugin at commit 66713730f07ff8fd6ac1222eef880f69f18166cd.
Are there any plans on implementing an easier way to configure keyboard shortcuts (as opposed to re-compiling)?
We have had a bad experience with that. At some point we were spending more time on fixing keyboard conflicts than on development. It's blocked for good. Also we don't want to do unnecessary file reads and writes.
I would love more useful plugins though.
I'd love to contribute but I don't have any ideas at the moment.
Would you consider enabling the user to deactivate shortcuts?
Which ones, for example?
Well, all of them. I like to lock down my stuff to a minimum of functionality. While I love nnn there's a lot of shortcuts that I simply don't use. And many of the ones I do use, I tend to forget.
I have to lookup copy/pasting every time I need it so I ended up creating a plugin for that as it enables me to have a central access point to my most used actions. Same thing with deleting.
That has resulted in me never using them. But the fact that they exist means that I could activate them by mistake which makes me slightly anxious...
If I simply know how to select stuff, I can do whatever I need using plugins.
I have to lookup copy/pasting every time I need it so I ended up creating a plugin for that as it enables me to have a central access point to my most used actions.
Understood. What if I tell you that you can have this plugin run with a custom keybind directly in the next release? For example, my notes file opens at :n now.
If you want to disable how do you propose to do that?
I have to lookup copy/pasting every time I need it so I ended up creating a plugin for that as it enables me to have a central access point to my most used actions.
Understood. What if I tell you that you can have this plugin run with a custom keybind directly in the next release? For example, my notes file opens at
:nnow.
That's exactly what I'm shooting for.
If you want to disable how do you propose to do that?
Programatically speaking, no idea.
Practically speaking I guess you could go full ham and make variable that removes all shortcuts except the most basic: up, down, j, k, q and enter.
Alternatively one could add codenames to the different functions and check for a blacklist environment array variable (NNN_DISABLED_FUNCTIONS) containing these.
That's exactly what I'm shooting for.
This is already available on master, try it. See the help in Misc section: :K xK Run plugin key K
@superDuperCyberTechno would it be possible to prepare a demo video of nnn plugins? Maybe pick a few which may interest devs?
@superDuperCyberTechno would it be possible to prepare a demo video of
nnnplugins? Maybe pick a few which may interest devs?
Of the ones I made and use? What's the end goal? - Like I mentioned, they are just reimplementations of things already in nnn...
No. A demo recorded video of plugins like ndiff, checksum, fzy-open, hexview, ndiff, nmount, pastebin, splitjoin, transfer etc.
You want me to make demonstration videos of the currently available plugins?
@superDuperCyberTechno that's correct! It would be real helpful for users newly adopting nnn.
And I meant a single short video demoing some or all of the plugins I mentioned above.
I also have some plugin improvement suggestions:
We can use ix.io and 0x0.st.
These would remove the dep on pastebin script and transfer.sh looks a bit shaky wrt. longevity.
Huh. Well, I'd love to help but I have a lot in the pipeline. I'll see what I can do.
Sure!
Looks like transfer.sh found a partner. I updated the pastebin plugin to use ix.io.
Rolled at #337.
@tbrodbeck you requested previews in this thread. It's available in master.
Most helpful comment
Awesome! Here you go: