ToDo list

[jarun]

Rolled from #1022.

Cooking

• do not end selection mode before running plugins/prompt/shell
• list open locations in active contexts in help page
• make option O_MATCHFLTR to discard filter key if no match
• configurable NNN_TMPFILE to cd on quit
• picker mode improvements
  • open tty for input if STDIN is non-tty
  • truncate output file before writing
  • do not double select a file on Enter
• no redraw during du calculation, show only current dir name
• plugin xdgdefault: add dmenu support

Up for grabs

• notcurses UI backend (notcurses ui backend #1014) [@KlzXS]
• support applying filter by key (like bookmarks/plugins)
• open new terminal window in spawned shell dir (Spawned shell (!) with kitty (--cwd=current) #759)

For anything else please discuss in this thread.

Contribution guideline.

[KlzXS]

We should mention patches in README and wiki. I can't do it this exact moment so I'm leaving it here as a note.

[jarun]

Added to the readme at commit e1a9aa0. We do not need to add this to the Wiki. I intentionally kept the documentation subdir like in case of plugins.

[luukvbaal]

In an attempt to improve performance of the gitstatus patch after coming across e.g. libgit2/libgit2#4230 and https://stackoverflow.com/questions/44340094/in-what-scenarios-libgit2-is-faster-than-git I wrote a version of the patch that parses git status instead of using libgit2: luukvbaal@10da9e1

Memory usage with this patch is ~2 as small when compared to the current patch, nnn binary is 0.4K smaller, prevents having to install the libgit2 dependency and "feels" faster as well although hard to profile.

I'm currently just directly printing the status column as represented by the git status --porcelain table i.e.

X          Y     Meaning
-------------------------------------------------
         [AMD]   not updated
M        [ MD]   updated in index
A        [ MD]   added to index
D                deleted from index
R        [ MD]   renamed in index
C        [ MD]   copied in index
[MARC]           index and work tree matches
[ MARC]     M    work tree changed since index
[ MARC]     D    deleted in work tree
[ D]        R    renamed in work tree
[ D]        C    copied in work tree
-------------------------------------------------
D           D    unmerged, both deleted
A           U    unmerged, added by us
U           D    unmerged, deleted by them
U           A    unmerged, added by them
D           U    unmerged, deleted by us
A           A    unmerged, both added
U           U    unmerged, both modified
-------------------------------------------------
?           ?    untracked
!           !    ignored
-------------------------------------------------

If desired we could add colors/use different characters like in the current patch.

Thoughts on this @jarun @KlzXS @crides @CantoroMC?

[jarun]

I am fine with this.

[crides]

Same. I used the libgit2 implementation as I followed how it was implemented in exa, so that I had a good reference for correctness. But parsing git itself is definitely faster

[pvxx]

Here are my three ideas after using nnn for a few weeks:

Selection markers - add new numeric env variable (NNN_MAXSELMARK?) and restore selection markers if number of selected files is lower that that (with value of 0 getting current behaviour); if number of selected items is bigger than this limit, highlight it in status line.

Reasoning: it is impossible to find a solution for huge selections with reasonable resource usage, but in the wast majority of real world cases the selection is small (for me it's like 90% 1-10 files, 9% 11-100, 1% 100+). This way users will be able to decide themselves whether they prefer convenience or speed/low resource usage. And speaking of speed, when I run 'fgrep -Ff' on files with tens of thousands of lines, it takes around 0.01s on my 10y old i5 cpu :).

Filename highlighting - add env variable (NNN_FNCOLOR?) for regexes and colors to use for file list (stop after first match) - like "{color1}:{regex1};{color2}:{regex2};..." (for example "c1:/(avi|mpg|mkv)$/;4f:/(gif|jpg|png|webp)$/").

I know this goes against design principles, but for me it's the thing I miss most from mc; limit is fine for some uses, but unusable for others. You already highlight special files and support regex in limit, so adding this should be simple. Since default would be empty (= current behaviour), users can decide themselves how simple/complicated (=slow) highlighting they want to use.

Limit string from command - instead of "bookmarks" add env variable (NNN_LIMITCMD?) for command which returns string to be used as limit regex; allows users anything from simple choice (using read/dmenu/...) to advanced stuff like special filters for specific directories, etc.

Thank you for your work, nnn is really great and is mostly a pleasure to use; apart from highlighting the only thing I miss is some more interactive cp alternative (overwrite/skip (all), etc.) :).

[jarun]

restore selection markers if number of selected files is lower that that

The problem is the implementation takes much more memory whatever be the number of files. Anyway, we have thought about it and there's no great solution.

10y old i5 cpu

P1 is old. Not i5. And we need to support handhelds.

for me it's the thing I miss most from mc

See if you can write a patch for the same. No plans form our side because we support instant filters using regex. Did you check the plugin which finds files by mime type as well (mimelist)?

instead of "bookmarks" add env variable (NNN_LIMITCMD?)

I don't understand. Please explain more clearly. There are some plugins for bookmarks. There are no plans to support new config variables.

[pvxx]

I know there is no great solution, that is why I propose a limit; if you set it to 0, you get exactly the same behaviour (and resource usage) as in current version. But why not have an optional functionality, that will be OK for 90+% of real-world cases? (And I suspect 90+% systems running nnn spend an order of magnitude more CPU and memory just rendering the text in terminal ;). I also don't understand the need for memory - just load the filenames from NNN_SEL for current dir (that is all the memory you need) and "brute-force" compare all of them with every (first time) shown filename - but maybe I'm missing something. Not very "nice", but a few hundred strcmp calls should not take significant time even on an 386 ;). Just for fun I tested grep -Ff with two 20+K line files on my GnuBee with MIPS 1004Kc processor (slower than P1 I think) and it took 0.15s (real).

Highlight: I didn't write anything significant in C for last 20 years ;), but if no one else is interested, I might try, when I find the time :).

Limit: mimelist - I didn't, thank you; it is interesting, but I don't really like the symlink-style. Would it be possible to set the limit-string (regex) using $NNN_PIPE? (Instead of sending filenames with +l.) That would allow what I want without adding new variables. And sorry for not being clear, it was a reaction to "support applying filter by key (like bookmarks/plugins)" item in your todo-list.

[jarun]

I don't need any of these and can't spend time even exploring solutions anymore. We have done these before.

If you need it, please write the filter thing. As you can see, no one else wants to pick it.

[pvxx]

Sorry for bothering you, given the number of closed issues mentioning this, it seems like something worth solving at least partially. And I personally would really like to understand what the resource problem is :), given that you only have to care for displayed items (some links to the discussions?). In any case, I understand if you don't want to open it anymore, thank you for your time.

Looking at the filter code I'm a bit lost :), could you give me a hint how to set a string (g_buf in readpipe in this case) into current filter? Thanks in advance.

[KlzXS]

@pvx- See #1086 for a patch for selection markers.

[Kabouik]

Speaking of selection:

Concurrent selections

There could be multiple .selection files bound to multiple keybindings, and a user could append files/folder to multiple independent selections. Selection markers could reflect the concurrent selection, for instance with braille characters like ⠁, ⠃, ⠇ (there are other characters that could work). Independent selections could be viewed in a similar way as concurrent buffers in text editors, and could be pretty useful in more than one situation.

For instance, imagine a messy folder containing pictures all named "DSC1234.jpg" and you want to split them into subfolders "Joe", "Kate" and "Pete". Currently you'd typically enable preview-tui and go through all pictures to select all pictures of Joe, move them into joe/, then go back, preview all remaining pictures to select those of Kate, move them into kate/, and then go back, rinse and repeat for Pete, and so on for as many subcategories you need. With concurrent selections, you could preview pictures only in one go and build each selection at the same time. I know this is just a very specific workflow, but it's also just an example, I think there are other situations where this could be useful.

I do not pretend it would be easy to implement or even within nnn's scope though, plus it would probably imply updating scripts too to ask which selection to use when multiple .selection.1 and .selection.2 files are found. Just an idea.

View selection(s)

As far as I know, there's no way currently to see which items are selected if we have changed folder, since the nnn UI does not retain selection marks after moving between folders.

This could be done with a plugin, and probably wouldn't be too hard to code (I have no time to do it now, but perhaps could work on it in a few weeks).

Even if the first idea of multiple selection is rejected, this may still have fill a need: I stopped counting how many times nnn asked me if I wanted to do an action on the selection or on the current file, and I did not remember what the selection contained unless I selected items just before. This would help reviewing cross-folder selections too.

[KlzXS]

As far as I know, there's no way currently to see which items are selected if we have changed folder, since the nnn UI does not retain selection marks after moving between folders.

I just submitted a patch for that but there is also E which opens the selection in $EDITOR so that you can not only see it, but edit it. There was some restriction, I think you can't add lines to it.

Concurrent selections

While I can see some merit to it the answer is no. That is just way too complicated and niche to implement. I just don't see it working out.

[Kabouik]

I just submitted a patch for that but there is also E which opens the selection in $EDITOR so that you can not only see it, but edit it. There was some restriction, I think you can't add lines to it.

I must be sleep deprived (or dumb): I know about it and actually use it quite often. I have no idea how I could write such a wall of text about it just above and not remember that I already use E in my workflow. My bad, sorry. Your patch is a great news too, I just read your PR message.

Yes, I understand your view on concurrent selections. Perhaps as a plugin one day, be it merged in master or just for me (though a plugin would limit the power of it as it would not integrate with base nnn functions, it could at least cover the example I used).

[jarun]

@KlzXS

I think you can't add lines to it

You can, but it's not supported.

[KlzXS]

Same difference in my eyes.
It clears the selection if you add anything.

[jarun]

Cool! We are hack-safe then.

[pvxx]

@pvx- See #1086 for a patch for selection markers.

Thanks a lot; for me it works great, I don't think I ever needed to select even 1000 files ;), everything I tested (including invert) works without noticeable delay. I hope you manage to include it into mainline :).

[jarun]

@pvx- can you please support @KlzXS with testing the patch?

[pvxx]

@pvx- can you please support @KlzXS with testing the patch?

Yes, of course; I also can compile it on one of our servers where we do have some real-world dirs with tens of thousands of files (but also quite powerful hardware and lots of memory). Anyway, just tell me what to do and I'll do my best :). I subscribed to the pull request conversation, if you want to communicate some other way just let me know.

[Kabouik]

Seeing that the treeview plugin is being removed and replaced in preview-tui, it might be worth mentioning that treeview did not work with all editors, especially those who don't need the - after a pipe. This is what I use for kakoune and micro:

#!/usr/bin/env sh

# Description: Show tree output in $EDITOR
#
# Shell: POSIX compliant
# Author: Arun Prakash Jana

case "$EDITOR" in
    kak | micro)
        tree -ps | $EDITOR
        ;;
    "")
        tree -ps | vi -
        ;;
    *)
        tree -ps | $EDITOR -
        ;;
esac

It should also default to vi if $EDITOR is not set. By the way I was surprised recently when I saw that tree is not installed by default on Raspbian, we might want an if to gracefully abort when tree is missing?

[roland-5]

1. Umm, I'm just curious, but are you planning maybe support for Hex palette (like blue is #0000ff) in future? I'm completly new to theming and different palette (rgb, hex, 256 xterm) and I'm little confused by 256 xterm palette.
2. Why option for coloring 1234 windows is seperated from others (dir, exe etc.)?

[jarun]

but are you planning maybe support for Hex palette (like blue is #0000ff) in future?

No.

Why option for coloring 1234 windows is seperated from others (dir, exe etc.)?

That's from the legacy implementation where we only had context colors.

[roland-5]

As a person who know nothing about coding and programming: To add Hex color palette I needed to know C as it needed to be add to nnn core or if I learn some language I could make plugin for it and it would still be good for nnn?

[jarun]

You'll need to do it in the core program. Plugins cannot affect this.

[0xACE]

As a person who know nothing about coding and programming: To add Hex color palette I needed to know C as it needed to be add to nnn core or if I learn some language I could make plugin for it and it would still be good for nnn?

haven't really looked at master in a while but look around the functions responsible for filling the file list in my case it's printent and printent_long but iirc they've moved on from that setup... and honestly you are probably better off sticking to your default 256 colors:

[jarun]

@superDuperCyberTechno please note that plugin uidgid will be removed in the next release as we support showing uid and gid using program option -U now.

[navneetankur]

The .lastd, file's location can be made configurable, similar to selection file. Because .lastd file is also supposed to be read by some other program, it doesn't need to always be in nnn's config folder.

[jarun]

Sorry, no plans to add another config/arg.

[jarun]

@navneetankur on second thoughts, it appears a good flexibility so I added it in commit f6856f6. Those who prefer to cd on quit always can configure it in NNN_TMPFILE.

[navneetankur]

Thanks, now it will be possible for me to keep it in the tmpfs.

[N-R-K]

It should also default to vi if $EDITOR is not set. By the way I was surprised recently when I saw that tree is not installed by default on Raspbian

tree doesn't ship by default on gentoo or arch/artix either, neither does vi
I assume its same with many other minimal distros.

[Kabouik]

It should also default to vi if $EDITOR is not set. By the way I was surprised recently when I saw that tree is not installed by default on Raspbian

tree doesn't ship by default on gentoo or arch/artix either, neither does vi
I assume its same with many other minimal distros.

Just out of curiosity, what is the default terminal text editor in Gentoo and Arch/Artix? I thought vi would be the most minimal and widespread so that's what I put in my version of plugins/treeview, but maybe there is something more sensible. I hesitated with nano but I don't think nano is as widespread in default installations.

Anyway, plugins/treeview is being removed, but I just wanted to emphasize that its current implementation didn't work with all terminal editors, so we should take that into account in the preview plugin that will replace it, and maybe add an if to test whether tree is installed.

[N-R-K]

Just out of curiosity, what is the default terminal text editor in Gentoo and Arch/Artix?

It's nano on gentoo. And iirc it's the same on arch/artix but I might be wrong on that.

[lawnowner]

Right now the selection mode is ended after running a plugin. I think it's better to keep it on unless the plugin requests the selection to be cleared so that additional files can be selected after a plugin changes the active directory via NNN_PIPE. Sometimes it's quicker to navigate via a plugin instead of navigating manually.

[jarun]

At least over the last 2 releases, plugins have to explicitly clear the selection: https://github.com/jarun/nnn/tree/master/plugins#create-your-own-plugins

[lawnowner]

Yes, it's the behaviour when the plugin does not clear the selection that I'm talking about:

1. Select a file.
2. Run a plugin that changes the active directory in the current context via NNN_PIPE but does not clear the selection.
3. Select another file.

Since running the plugin ended the selection mode even though the plugin didn't clear the selection, additonal files cannot be selected in the new directory, where selecting a file restarts the selection mode and thus discards the previously selected file.

[pvxx]

I just want to add that this happens when you run a shell (!) or cmd prompt (]) as well - doesn't matter whether you actually run a command or exit it immediately, after you select a file the whole "old" selection is cleared and current one only contains this one file.

[jarun]

So you are telling me that you are using a tool that has awesome support for navigation and bookmarks and yet you need change in the program logic because you can't move away for third-party utilities for navigation?

The problem is using nav tools within a nav tool for navigation.

endselection() is not just ending selection mode. It does something more that I do NOT have the time to decipher right now.

Feel free to read the code and fix it yourselves. That's what I expect from long time contributors.

@KlzXS FYI.

[jarun]

I think we are also replacing the listing root dir prefix with the actual file path prefix here.

[jarun]

I have made the necessary change at 62a0486.

@KlzXS please confirm if this affects the case where some files are selected from the listing tmp dir and the user invokes plugins multiple times. Would we see duplicate entries?

[KlzXS]

After the selection has ended the listing root path would get replaced and you'd now have the real path in selection. Which means that, yes, you could get a duplicate.

Does it really matter? I'd say no.

[jarun]

Ok, done!

[pvxx]

I have made the necessary change at 62a0486.

Works for plugins now, is it possible to do it for shell/cmd as well? Because I run shell very often and losing the ability to update selection every time is really inconvenient (I ran into that a few days ago and wanted to report it myself :). But it is definitely not a critical issue, so if it is a technical problem, I'll manage ;).

Btw. I also use custom plugin for navigation ;), since at work I often need to temporary work with multiple deep paths and (AFAIK) there is no way in nnn to set multiple bookmarks in UI itself; in mc I used directory history, now I have a small plugin that can set/store/recall directory for stored ones (using rlwrap), which is much better ;).

[jarun]

Try commit 75b5069.

[pvxx]

Works :), thanks a lot.

[jarun]

I reverted the last one. It's simply dangerous for people who select something and run a command on it.

Please use the patch locally for your use case.

[jarun]

Because I run shell very often and losing the ability to update selection every time is really inconvenient (I ran into that a few days ago and wanted to report it myself

What's the frequent use case where you start a selection, go to shell to do something and then return to resume the selection? And why is it so important to run the command in between and cannot be run at the end of selection? What's stopping you from bringing in that discipline in your workflow?

[jarun]

I think people should use $nnn instead. Adding it back.

[jarun]

See commit 49ee5b2.