Nnn: ToDo list

Created on 21 Sep 2019  路  65Comments  路  Source: jarun/nnn

Rolled from #329.

Ready for next release

  • user requests addressed

    • plugins for image preview, image and video thumbnails

    • redesigned selection workflow

    • drop path prefix for files in current dir for selection based archives

    • custom direct keybinds for plugins

    • libreadline .history file moved to nnn config directory

    • export current entry as $NN at command prompt

    • more informative status bar in light/detail modes

    • auto-proceed to next file on single file select

    • path clipping for long paths

    • completely revamped wiki

  • new program options

    • -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_PROG

  • plugin changes:

    • vidthumb - show video thumbnails in terminal

    • mediainf - 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 directory

    • oldbigfile - list large files by access time

    • moclyrics - show lyrics of the track currently playing in MOC

    • uidgid list uid and gid of files in directory

    • mocplay - now detects if a track is playing or not

    • organize - categorize files and move to respective directories

    • pastebin - now uses ix.io paste service

    • fzy-edit - merged into fzy-open

    • viuimg - fix directory view

    • checksum - fixed POSIX compliance issues

    • boom - play music in MOC

  • keybind changes:

    • select all key: a

    • select range (or clear selection on repeat) keys: m and ^K

    • select entry key: Space and ^J

    • list selection key: M

    • ^N replaces ^T to toggle _nav-as-you-type_

    • Shift TAB to reverse context cycle

    • ' to jump to first file in dir

    • S for du, A for apparent du

    • additional key : to run plugin

    • additional key F2 to rename file

    • additional key F5 to redraw

    • quit context key Leadq is removed

  • Leader key combinations:

    • Lead' to jump to first file in dir

    • Lead] go to next active context

    • Lead[ go to prev active context

    • Lead. toggle show hidden files

  • improved duplicate file workflow
  • improved batch rename workflow when a selection exists
  • removed the wild load option (-w)
  • removed quick notes (added plugin notes)
  • fix #225 (thanks @KlzXS)
  • fix tar/bsdtar always creating tar archives (and not by suffix)
  • fix single mouse click to select file not working
  • fix symlink to dir removed on batch rename
  • fix detail mode not set with program option -S

Proposed features and tasks (up for grabs)

  • [ ] a video exploring nnn plugins
  • [ ] wikipedia page
  • [ ] session support (max 4 directories)
  • [ ] script to duplicate selection in respective directories
  • [ ] refactor function browse()

Anything else which would add value (please discuss in this thread).

List of completed features and tasks.

Most helpful comment

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

All 65 comments

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):

  1. launch nnn
  2. resize the terminal window size (resize down)
  3. exit nnn
  4. _the problem:_ you are able to see text from the closed nnn 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 nnn window 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:

  1. Make sure 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 operation
  2. Horizontal split a new pane, where the cp/mv command runs
  3. if all goes well the pane disappears when the process is finished.
  4. If there was a error pause the screen and let the user see the message and close it by hitting any key

(At least this is what my plan is and note that I use advcpmv)

https://www.samuelthomasdavies.com/elevator-waiting-times/

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:

  1. run cd ~/example && dvtm
  2. within the dvtm session type cd .. to go back a directory, you should be in ~
  3. Spawn a new shell in dvtm with Mod-C (which is suppose to open a new shell in the active shells CWD) (Notice it's a capital C)
  4. Result: 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:

  • No need to end selection mode manually, it's auto-ended (function endselection()) before cp/mv/rm selection, batch rename, create archive, link and run cmd, exec file, launch app, run plugin operations.
  • Please review the new key mappings. Please refer to the latest program help in code for this.

@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 -laht as 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 :n now.

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 nnn plugins? 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lenormf picture lenormf  路  6Comments

kuntau picture kuntau  路  3Comments

weatherbell picture weatherbell  路  8Comments

harriott picture harriott  路  6Comments

tim77 picture tim77  路  9Comments