Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ToDo list #1040

Closed
7 of 10 tasks
jarun opened this issue Jun 2, 2021 · 50 comments
Closed
7 of 10 tasks

ToDo list #1040

jarun opened this issue Jun 2, 2021 · 50 comments
Labels

Comments

@jarun
Copy link
Owner

jarun commented Jun 2, 2021

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

For anything else please discuss in this thread.

Contribution guideline.

@KlzXS
Copy link
Collaborator

KlzXS commented Jun 4, 2021

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
Copy link
Owner Author

jarun commented Jun 4, 2021

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
Copy link
Collaborator

luukvbaal commented Jun 24, 2021

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
Copy link
Owner Author

jarun commented Jun 24, 2021

I am fine with this.

@crides
Copy link

crides commented Jun 24, 2021

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
Copy link
Collaborator

pvxx commented Jun 28, 2021

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
Copy link
Owner Author

jarun commented Jun 28, 2021

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
Copy link
Collaborator

pvxx commented Jun 29, 2021

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
Copy link
Owner Author

jarun commented Jun 29, 2021

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
Copy link
Collaborator

pvxx commented Jun 29, 2021

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
Copy link
Collaborator

KlzXS commented Jun 29, 2021

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

@Kabouik
Copy link
Collaborator

Kabouik commented Jun 29, 2021

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
Copy link
Collaborator

KlzXS commented Jun 29, 2021

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
Copy link
Collaborator

Kabouik commented Jun 29, 2021

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
Copy link
Owner Author

jarun commented Jun 29, 2021

@KlzXS

I think you can't add lines to it

You can, but it's not supported.

@KlzXS
Copy link
Collaborator

KlzXS commented Jun 29, 2021

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

@jarun
Copy link
Owner Author

jarun commented Jun 29, 2021

Cool! We are hack-safe then.

@pvxx
Copy link
Collaborator

pvxx commented Jun 29, 2021

@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
Copy link
Owner Author

jarun commented Jun 29, 2021

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

@pvxx
Copy link
Collaborator

pvxx commented Jun 30, 2021

@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
Copy link
Collaborator

Kabouik commented Jul 2, 2021

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
Copy link

  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
Copy link
Owner Author

jarun commented Jul 11, 2021

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
Copy link

roland-5 commented Jul 11, 2021

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
Copy link
Owner Author

jarun commented Jul 12, 2021

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

@0xACE
Copy link
Collaborator

0xACE commented Jul 12, 2021

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

@jarun
Copy link
Owner Author

jarun commented Jul 17, 2021

@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
Copy link

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
Copy link
Owner Author

jarun commented Jul 24, 2021

Sorry, no plans to add another config/arg.

@jarun
Copy link
Owner Author

jarun commented Jul 25, 2021

@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
Copy link

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

@N-R-K
Copy link
Collaborator

N-R-K commented Jul 28, 2021

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
Copy link
Collaborator

Kabouik commented Jul 28, 2021

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
Copy link
Collaborator

N-R-K commented Jul 28, 2021

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
Copy link
Contributor

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
Copy link
Owner Author

jarun commented Aug 8, 2021

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
Copy link
Contributor

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
Copy link
Collaborator

pvxx commented Aug 8, 2021

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
Copy link
Owner Author

jarun commented Aug 8, 2021

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
Copy link
Owner Author

jarun commented Aug 8, 2021

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

@jarun
Copy link
Owner Author

jarun commented Aug 8, 2021

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
Copy link
Collaborator

KlzXS commented Aug 8, 2021

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
Copy link
Owner Author

jarun commented Aug 8, 2021

Ok, done!

@pvxx
Copy link
Collaborator

pvxx commented Aug 8, 2021

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
Copy link
Owner Author

jarun commented Aug 8, 2021

Try commit 75b5069.

@pvxx
Copy link
Collaborator

pvxx commented Aug 8, 2021

Works :), thanks a lot.

@jarun
Copy link
Owner Author

jarun commented Aug 8, 2021

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 jarun closed this as completed Aug 8, 2021
@jarun
Copy link
Owner Author

jarun commented Aug 8, 2021

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 jarun reopened this Aug 8, 2021
@jarun
Copy link
Owner Author

jarun commented Aug 8, 2021

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

@jarun
Copy link
Owner Author

jarun commented Aug 8, 2021

See commit 49ee5b2.

@jarun jarun closed this as completed Aug 8, 2021
Repository owner locked and limited conversation to collaborators Aug 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests