Rolled from #337.
NNN_ARCHIVE)nuke: sample opener (CLI-only by default).cbcp: copy selection to system clipboard.ntfy: show notis on cp, mv, rm completionautojump: navigate using autojumpupload (previously transfer), uses https://file.io- to skip dir refresh after running (cmd as) plugin* to skip confirmation after running cmd as pluginfzf and fzy*-f to run filter as prompt on prompt key (can be disruptive)-x: enable notis and copy selection to system clipboard-g: regex filters (substring filter is default now)-Q: quit program without confirmation-s: load session (earlier -e)-n: start in nav-as-you-type mode (earlier -i)-v: version sort (earlier -n)-V: show program version (earlier -v)-A: disable dir auto-select (earlier -t)getplugs to install hidden filesstat() on target failsdirent.d_type)nnn.vim plugin to show a persistent bar (https://github.com/mcchrish/nnn.vim/issues/46)nnn pluginsAnything else which would add value (please discuss in this thread).
List of completed features and tasks.
Hey, I think i encountered the lastdir problem described in: https://github.com/jarun/nnn/commit/20ac9da98852367646e2c3b195fcbfee844cca72#commitcomment-36198570
appear in commit: f80563e16a981deeaca43e17b48dbf6ca0ed0efd
as I was on the run, I didn't have time to note which commit i was on when it happened, and since then I have rebased on master... I tried reproducing it though and I can't anymore, so I'm not sure if that build was spooked somehow...
I think it's fixed in master. Please try a few more times with the release.
I tried again, it happened again. I'm not exactly sure how to reproduce it.
I can't reproduce it in a "testing" scenario, the problem appears when I'm using nnn naturally...
I am not sure how this helps. We had days to test this before the release and I did call out to all of you to pitch in. Your _natural_ usage is not helping me to reproduce this.
@0xACE any luck yet? Please confirm you are on master.
@maximbaz can you please help us repro the issue @0xACE is seeing?
Will try, but after you pushed https://github.com/jarun/nnn/commit/ef88a31a7ce632f35b538ff64466489902076883 and https://github.com/jarun/nnn/commit/0a5dc2e336cfa3aab64783fb44b0be519e46750c I've had zero issues with selection. If I spot it, I'll let you know right away.
Yes, even I am not seeing this.
@0xACE I also took a look at master source to track if we are clearing lastdir anywhere but I couldn't find any such instance.
I am not sure how this helps. We had days to test this before the release and I did call out to all of you to pitch in.
I did try it out in my limited time, and I don't recall that I encountered it
Your _natural_ usage is not helping me to reproduce this.
Yeah, atm I don't have a way to describe it because I don't understand it myself.
@0xACE any luck yet? Please confirm you are on master.
Yes I am on master.
Will try, but after you pushed ef88a31 and 0a5dc2e I've had zero issues with selection. If I spot it, I'll let you know right away.
No need to push yourselves, I haven't confirmed it myself, I was mostly wondering if someone else is encountering this issue.
@0xACE I also took a look at master source to track if we are clearing
lastdiranywhere but I couldn't find any such instance.
Yeah, I haven't looked at the code yet. As I don't know how to reproduce it, I'm just gauging if someone else has this problem.
I'll let you know next time I encounter the problem. For now there is not much I can do about it...
One thing both occurances had in common was that I selected a folder for a that was being downloaded via torrent. I left nnn running while that torrent was downloading, and when it finished, I went back to nnn to try to move the selected folder, and thats when I noticed the selected path was incorrect... But I'm not sure how that affects nnn...
One thing both occurances had in common was that I selected a folder for a that was being downloaded via torrent.
I'll try this.
And no luck! I've made the minor release already. If it's really an issue we will surely get user reports and we can fix it when we have some more concrete data.
Happened again, this time there were no torrents involved.
I'm disabling all my personal patches just incase this problem is caused by my changes. I'll let you know next time...
Btw is it important to K flush the selection? because I have never used it, and I don't think I intend to use it...
Btw is it important to K flush the selection?
Not for flush, not really. Because of your use case, I made the flush to .selection file auto. But yes, it's required to edit.
@maximbaz can you check if there's any way to reduce the binary size further? For me it is 62.1 K now. I would love to bring it below 60 K.
I'll have a look, out of curiosity, can you share the full command that you use to compile?
If I run make locally, it executes the command below, resulting in 93kb file.
cc -Wall -Wextra -O3 -D_GNU_SOURCE -D_DEFAULT_SOURCE -o nnn src/nnn.c -lreadline -lncursesw
If I run make on the build environment for Arch Linux (this is what we distribute to users), make executes the command below, resulting in 87kb file.
$ cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wextra -O3 -D_GNU_SOURCE -D_DEFAULT_SOURCE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o nnn src/nnn.c -lreadline -lncursesw
here's what I see on Ubuntu 18.04, amd64:
~/GitHub/nnn$ sudo make O_NORL=1 strip install
cc -DNORL -Wall -Wextra -O3 -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -o nnn src/nnn.c -lncursesw -ltinfo
strip nnn
install -m 0755 -d /usr/local/bin
install -m 0755 nnn /usr/local/bin
install -m 0755 -d /usr/local/share/man/man1
install -m 0644 nnn.1 /usr/local/share/man/man1
~/GitHub/nnn$ ll nnn
-rwxr-xr-x 1 root root 63616 Dec 17 18:11 nnn*
~/GitHub/nnn$
@annagrram shall we remove the "@" session after we restore it? I think currently it's not happening. I don't remember if we talked about this during implementation.
@annagrram shall we remove the "@" session after we restore it? I think currently it's not happening. I don't remember if we talked about this during implementation.
We haven't talked about it, but yeah. Sure
I have checked-in the change already at commit cf388649b9cd6fba38b9c0dca49c29bad3b6f737. Please review once.
Just a quickie: I tried opening a file which had a ' in it: example This Boy's Life with ^o (CTRL-o) and it failed to open it. anyone else having problems with this?
which application did you try to open it with?
which application did you try to open it with?
a personal tool i made. But nvm, I can't reproduce the error anymore. I thought maybe i misspelled my tool, but looking at the history, i did write it in correctly.
Anyhow, since I can't reproduce it, it's most likely a user error on my end and not nnn related.
On the other hand is anybody experiencing "swallowing of input", i.e. after ^o if you try to open a cli program as gui (it seems to not work for every program but for vim it does), every second keypress doesn't do anything. This also persists even after exiting nnn until the terminal is closed. Also affects ttys.
if you try to open a cli program as gui
please don't do this. It will mess up your terminal. Open a CLI program as cli and GUI program as gui. I don't think we will be able to support the inter-mixing with any kind of hacks. We can't detect ourselves whether a executable is GUI or CLI.
@0xACE
Is the tool a cli-only opener? or does it invoke a gui program?
please don't do this
This time I did it on accident but I think this also happens sometimes with some files when it doesn't know with what to open it. At least it did in the past. Just by using l, Enter.
What's your opener?
If it's a text file do you have NNN_USE_EDITOR set?
Is the tool a cli-only opener? or does it invoke a gui program?
It's a cli only tool. It has no GUI elements involved.
I reckon it's safe to dismiss my "error". There is a good chance I actually made a mistake. As this problem appeared in my "regular" usage of nnn I didn't think to debug it, and by the time i "realised" that there might be wrong, I had already closed the window. Since none of use can replicate it atm, maybe it really was me making a mistake.
Btw regarding the cli vs gui prompt in ^o: I always thought that in the ^o context that gui was just a cover up for running the process in the background.
I always thought that in the ^o context that gui was just a cover up for running the process in the background
There's more to it. For gui programs, we do not wait and we also disable their stdout and stderr. Some UGI programs write debug and errors to stdout/stderr. That breaks the nnn interface.
In case of CLI programs, we spawn them, wait and also show their output.
@jarun regarding executable size, I was searching how to get the most significant results and discovered compression tool called upx.
On my local machine, upx --best nnn compresses the nnn binary from 79904 bytes down to 39960 bytes!
Do you know about this tool? Any drawbacks in using it?
Some basic disadvantages listed are:
- Special permissions are ignored, such as聽suid.
- argv[0]聽will not be meaningful.
- Multiple running instances of the executable are unable to share common segments.
Not sure if we really care about those. But it does sound cool.
@maximbaz
Do you know about this tool? Any drawbacks in using it?
But we would have to unpack it each time when we load, right?
Let's leave that. strip is good enough. We should try to see from code perspective if we can do something.
I saw on the linuxquestions site that you were looking for feature suggestions, personallyy I rather liked the grouping mechanism that windows explorer has and find it annoying that no linux file manager has that feature, perhaps you could lead the charge and implement one? Doesn't have to be on by default but by golly it makes manual searches easier
Can you explain grouping? I seldom use Windows.
Can you explain grouping? I seldom use Windows.
Me too. But a quick YouTube search yielded this: https://youtu.be/k_mlcPonzGo?t=485
Thanks @annagrram!
As I can see, there are 4 grouping params: name, modification date, type, size. We support all 4 (and more).
@awsdert please press d to enable detail mode and use the respective sort keys to show the files ordered in the way.
default is by name, so look for the order in the file name column. For date, use the first column, for size see the size column.
Type in case of nnn would be extension. So order by extension and I think in this case the light mode would be helpful as you may want to see the full name. Note that we also show the extension in the status bar.
For example, this is what I see in plugins dir when I sort by mod time:
2020-01-07 22:11 664 9.3K README.md
2020-01-06 19:26 775 428B* autojump*
2020-01-06 19:26 775 928B* boom*
2020-01-06 19:26 775 661B* fzcd*
2020-01-06 19:26 775 896B* fzhist*
2020-01-06 19:26 775 588B* fzopen*
2020-01-06 19:26 775 1.4K* getplugs*
2020-01-06 19:26 775 619B* imgview*
2020-01-06 19:26 775 1.1K* launch*
2020-01-06 19:26 775 15.8K* nuke*
2020-01-06 19:26 775 770B* pskill*
2020-01-06 19:26 775 780B* upload*
2020-01-01 00:23 775 2.1K* chksum*
2020-01-01 00:23 775 1.2K* diffs*
2020-01-01 00:23 775 1.8K* dragdrop*
2020-01-01 00:23 775 539B* dups*
2020-01-01 00:23 775 1.5K* gutenread*
2020-01-01 00:23 775 184B* hexview*
2020-01-01 00:23 775 771B* imgresize*
2020-01-01 00:23 775 310B* imgthumb*
2020-01-01 00:23 775 20.3K* imgur*
2020-01-01 00:23 775 250B* ipinfo*
2020-01-01 00:23 775 637B* kdeconnect*
2020-01-01 00:23 775 254B* mediainf*
2020-01-01 00:23 775 1.1K* moclyrics*
2020-01-01 00:23 775 2.1K* mocplay*
2020-01-01 00:23 775 1.4K* nmount*
2020-01-01 00:23 775 318B* oldbigfile*
2020-01-01 00:23 775 1.4K* organize*
2020-01-01 00:23 775 733B* pdfread*
2020-01-01 00:23 775 615B* pdfview*
2020-01-01 00:23 775 606B* picker*
2020-01-01 00:23 775 1K* renamer*
2020-01-01 00:23 775 942B* ringtone*
2020-01-01 00:23 775 1.3K* splitjoin*
2020-01-01 00:23 775 408B* suedit*
2020-01-01 00:23 775 139B* treeview*
2020-01-01 00:23 775 208B* uidgid*
2020-01-01 00:23 775 658B* upgrade*
2020-01-01 00:23 775 559B* vidthumb*
2020-01-01 00:23 775 835B* wall*
And the date column gives me the grouping in a quick glance. I think when you are looking for a specific filename you still need to look into the filename both in Windows and in nnn.
If you are looking for the specific horizontal line kind of separation, that will not be possible without a major view overhaul (and conditional checks in the sorted entries as well). I don't think the ROI is great with what we already have today.
It would be a nice feature to display the mime-type of a file in the detail-view as this information is need to configure applications for the file-openers. The mime-type is already determined when a file is edited, so I guess it would be easy to add.
When does the version-number change?
I have nnn both from the debian-repository and compiled the head myself.
Both display 2.8.1 as versions but they behave diffferently (eg toggle of execution-flag does not exist in the debian version).
The mime-type is already determined when a file is edited
Only if NNN_USE_EDITOR is set and only when we open/edit it. But not when rendering file info as that would need calling file on all listed files affecting performance.
I am inclined to show it in the status bar _for the current file_ but some of the mime types can be quite lengthy and will push out vital info.
as this information is need to configure applications for the file-openers
As this is an infrequent operation, how about showing it in the file details screen? I think even today we invoke file there.
When does the version-number change?
Just before making the release. So master is still at 2.8.1 we changes on top of last-released v2.8.1.
Showing the mime-type in the file details screen for the current file only is what I meant.
Mime type shown at commit 5cb39b0db36a4afd30a0578799cd85dc28ed153c. ;)
perfect.
What I would like to have is way to reverse the sorts.
So when I press "z" the entries are sorted by size, decending.
I would like to press maybe "Z" and have the entries sorted by size but ascending.
Unfortunately such a logic currently cannot be extended as sort by extension is "E" while "e" is edit, but it seems you are currently discussing key-bindings anyway, so maybe it would be worth it to make some changes to have a general approach in the form that descending sorts have lower-case letters and the corresponding ascending sort has the upper-case letter or something like that...
Why would we have a keybind for reverse sort for every sorting mechanism? Why not have a single key that reverses the sort independent from which mechanism you are using?
If that is possible it would be even better.
"nnn -z" does not seem to work. Is there a way to set the preferred sort mode on the command-line?
If not, that would also be nice to have.
Reverse has been discussed earlier. Please see issue #377. My stand hasn't changed on this one. It's trivial to rollover at an edge or press G to jump to the last file and see in reverse.
"nnn -z" does not seem to work.
There is no such option (try nnn -h). Only 2 sort orders (which are likely to be set constantly) are available - -v and -S.
@KlzXS I must go to sleep now. It's 4:30 in the morning here.
For reverse, can you throw in a quick PR and we can check it out? I am not very inclined to have it but I would like to evaluate how much it affects our comparison... do we add checks in each case or we can drive the sorting functions to do this automatically without any condition checks?
I want to avoid hacks in every condition and that's the reason I'm avoiding this. It's trivial to look at the files in reverse. To reverse with a key or to jump to end and look in reverse all you need is a single keypress.
Your reasoning about reverse sorts makes sense (from a a functionality point of view), nevertheless I for one never really used file managers, so I am used to seeing the files I am interested in at the bottom of an ls output.
So when I am interested in large files in a dir with many entries, I sort in such a way that ls displays these files at the end.
When using nnn I now have to re-adjust, which is doable, however I can't quite see the point in not implementing something that is not hard but would faciliate usage.
But it's certainly not a dealbreaker.
I'll take a look at it tomorrow.
I can't quite see the point in not implementing something that is not hard but would faciliate usage.
Please raise a PR and we will revisit this.
I'll take a look at it tomorrow.
Sure!
I would like to see the current active filter in the status line.
I would like to see the current active filter in the status line.
And I would like people to look at the code and make _simple_ changes rather than making this their wishlist. ;)
@KlzXS I am looking into the reverse thing.
Reverse sort is implemented at commit f654e3ca2b95bebf4596b471172c91feadfd2555.
And I would like people to look at the code and make _simple_ changes rather than making this their wishlist. ;)
I hope you'll forgive me, but I'm going to do just that.
@jarun next time you edit the README, please remember to add Haiku to the supported platforms ;)
I hope you'll forgive me, but I'm going to do just that.
Oh, you have contributed so many features I use happily everyday but would never have spend the time to add in nnn.
@jarun next time you edit the README, please remember to add Haiku to the supported platforms ;)
Sure thing!
Great stuff, I like the reverse sorting.
There is one more issue with sorting for me (sorry to expand my wishlist again - feel free to ignore it of course):
When I filter a directory I can toggle between detail view and simple view with "d" and that keeps the filter active.
However when I filter a directory and then press eg "z" to sort by size my intention would be to sort the filtered list - however what happens is that the filter is reset and I get a sorted list of the entire directory.
Not sure if this is the intended behaviour but it would be nice if filtering and sorting would be orthogonal.
However when I filter a directory and then press eg "z" to sort by size my intention would be to sort the filtered list - however what happens is that the filter is reset and I get a sorted list of the entire directory.
In brief, sort a filtered view. Yes, we can look at it.
BTW, do you think showing the filter all the time is significant? I want to avoid this because the status bar is kind of well-populated today and a filter can be up to many characters long.
BTW, @annagrram and @KlzXS I am adding a ToDo. Feel free to explore when you get time. It's like whenever we type and move to the rightmost column, we should be able to show the next chars typed. And if we ever think of doing it, how about scrolling long status bars automatically? ;)
Maybe displaying the filter expression all the time is not neccessary but when I apply a filter and move up and down I can no longer see what exactly is filtered. Some way of getting to the filter may be useful sometimes, but maybe not so important.
And I would not want a scrolling status bar.
The status bar imho wastes some space by displaying the extension all the time - even in cases where the file name is short and I can easly read off the extension.
Currrently the end of the status line is eg
.txt [shortfile.txt] # extension is redundant
.txt [looooooongfile # closing bracket is dropped
Maybe one could save space by using
shortfile.txt # everything fits all info present
looong...txt # ellipsis indicates file name has been shortened but extension is visible
ellipsis indicates file name has been shortened but extension is visible
This would need unicode conversion and stuff to calculate number of chars vs. columns, which we are avoiding now by just printing.
Also note that this way we do not need to count how many chars are printed already and all goes in a single print.
I see. But is there actually any point in displaying the filename at all in the status bar?
I mean I can see the filename in the list window - it's the currently selected entry.
And a minor (cosmetic) thing:
Whenever I sort two (or in the reverse case three) characters are inserted into the status bar, which makes eg the timestamp "jump" whenever I sort and unsort.
I would prefer a few extra blanks for the case when no sorting is active, so that all the file information stays excatly where they were whenever I change the sorting. But that's just my taste...
But is there actually any point in displaying the filename at all in the status bar?
I think we can remove it.
I would prefer a few extra blanks for the case when no sorting is active
Space is precious. Let's not change the current behaviour.
But is there actually any point in displaying the filename at all in the status bar?
Now I remember why I had it. When scrolling up or down the list I look up the filename in the status bar. Just a small convenience.
As for filtering, I find that I tend to use the same filters again and again.
Would it be an idea to have an environment-variable like the bookmarks to pre-define filter-expressions that could then be applied with a key-stroke so you don't have to re-type your most common filters again and again?
What I would find extremely useful would be a way for an external program to define a filter, in the sense that the external script runs, determines a list of files of the current directory meeting some complex condition and communicates that list back to nnn (similar to the way an external program can change the directory) and nnn would then display this list.
So arbitrarily complex filters (taking into account more than just filename patterns) would be possible while nnn would stay simple.
btw: Is it documented somewhere that the .selection-file may contain duplicates, so that every external script that uses that needs to be prepared to handle the case that one and the same file may occcur several times?
The dir won't reload on sort order change (other than du related) with commit 4c0210ce2b50dab849874e86f7d61549a667d138.
Would it be an idea to have an environment-variable like the bookmarks to pre-define filter-expressions that could then be applied with a key-stroke so you don't have to re-type your most common filters again and again?
I can't invest my time on this. I will add a line item.
What I would find extremely useful would be a way for an external program to define a filter, in the sense that the external script runs, determines a list of files of the current directory meeting some complex condition and communicates that list back to nnn (similar to the way an external program can change the directory) and nnn would then display this list.
What's the use-case? Let's say you want to filter by time and you will feed in a range. Similarly for size. First, turning nnn into find is not _simple_ and secondly why would we want to do something (find and list) that find already does today?
Is it documented somewhere that the .selection-file may contain duplicates
Not specifically. I'll update the docs.
My use case would be for nnn to assist when you need to have some manual interaction with a list of files that is defined by some complex criteria in a directory.
An (admittedly contrieved) example would be all the video files in a directory that exceed a certain size and are not older then a week.
I want to manually go through this list (as some re-ocurring task) and decide on a file-by-file basis which of these to delete and which to keep.
Now if I could have an external script that would make this selection and nnn displays this for me, I could simply go from file to file and depending on the file, either go to the next (I have seen this video and know I want to keep it), delete it (I have seen it and know I don't want it) or open it to have a look when I can't tell from the filename.
The non-scriptable manual interaction (maybe I have to look at a video before I know what to do with it) is where nnn could be a great help (especially as when you can do all sorts of things with a file via plugins), but sometimes the selection of files on which you want to work on is not expressible by filename-patterns alone.
This is just to illustrate what I was thinking about - any maybe this is not what you intend nnn to be used for.
OK. Got it.
Now if I could have an external script that would make this selection and nnn displays this for me
First of all, this would work best with subtree search and nnn doesn't have a subtree view. What I think would be possible is - if the files are in the same dir, nnn can read the list from an input file (e.g. the output of find with one entry in each line) and load the file details (we will need a new api for that).
@annagrram or @KlzXS would you like to try it out?
So I take a list of entries to display from a file and then let the user operate on them. Basically creating a virtual directory. Am I getting this right?
Exactly!
And now I don't think we need to limit ourselves to a single dir as well. We can just stat the files to fill the data and show them.
The path to the hovered file can be shown in the top row as we do today. Try to keep the workflow as separate as possible.
I don't know what a subtree view is, but being able to load a list of files (all from the same dir) into nnn and then being able to have my way with them is all I would need.
That would open a lot of possibilities I believe.
OK. A single directory simplifies it. But say movie files... they are seldom within the same dir.
I don't really care where the files are, I am more concerned with how should this, mode, view, how should we call it, behave. What should happen if I try to create a file with n. I probably shouldn't allow it since it's not a real place we are showing at the moment. What else should be forbidden?
Would it be possible to have my_script.pl | nnn - (i.e. to have a script generate a list of files and feed that directly into nnn without a temporary file?
btw: If you have an executable file 'a' and a non-executable file 'a' (not very likely I know) they will be displayed in the exactly same way as you cannot tell if the training "" is part of the filename or the decoration of an executable.
Not really a bug though...
@ghistes You can always look at the status bar at the bottom. The name is also displayed without the trailing *.
@KlzXS: The most intuitive way for me would be to restrict this to one dir. It's essentially a filter on a dir. No need to restrict anything. A new file can be created, unless it already exists in the dir.
I guess I went a bit ahead with this. In a single dir there is much less to worry about.
What else should be forbidden?
Anything that doesn't deal with stat of these files. We should allow playing, invoking plugins, Up/Down/Scroll.
No back.
I would suggest a function separate from browse() with the min subset of operations.
I guess I went a bit ahead with this. In a single dir there is much less to worry about.
If we have a separate function it will get simpler. Just stat all the files by absolute path (or with current dir as base if relative path). malloc() the memory needed for path. Add a pointer in struct entry to point to the path. Release the memory allocated for paths on quit.
Would it be possible to have my_script.pl | nnn -
I think @KlzXS will handle it that way.
@KlzXS limit it to a directory. It will remain much straightforward and you can run all ops, reuse the browse() API.
@annagrram I have added a line-item to redraw only affected lines on Up/Down key navigation. Could you take a look at it?
reuse the browse() API
That sounds much better that duplicating code.
I think @KlzXS will handle it that way.
Do we really want to handle it this way? We would need to read in the whole thing before starting ncurses, right? I think that's how it works. Also where do we exit after the fact?
It would of course be even cooler to have this across a tree.
It would be a filter on a tree.
nnn displays only a subset of the files, but is of course aware that there are more, so all operations would be possible unless they collide with an existing file that is not visible.
Should a file in the input-list not exist, it's an error and nnn simply dies.
Should a file in the input-list not exist, it's an error and nnn simply dies.
I'm more for the ignore approach. If no files are left, exit.
I don't get the tree part.
An input of
/a/b/c/d1
/a/b/c/d2
/a/b/c/d3/e
would only show files "d1" and "d2" directory "d3" in /a/b/c and a file "e" in /a/b/c/d3.
If the user then tries to create a file /a/b/c/d3/f and that already exists it's an error, but if it does not exist he can create it.
If any of these do not exists then the script that generated the list has made an error.
The safe thing to do (in my opinon) is then to say "sorry, you made an error" and not continue any further.
@KlzXS limit it to a directory
Will do this first. Then might consider a subtree. I get what you want it to do now.
One dir would already be a fantastic addition.
But I would rather err on the safe side. If anybody pumps invalid data (ie a file in a list that does not really exist) into nnn it's his fault. nnn should simply die.
Will do this first. Then might consider a subtree.
I still don't think single dir would be useful. Let's try multi-dir. We can take more time to discuss and ideate.
Sure thing.
For curiosity: The "next" release is when you feel like it or do you have releases every n months?
And you should absolutely advertise (in your quickstart) that you add features by the hour and stress that compilation is trival, so people should use the head-version, rather than what gets packaged by the distributions.
Let's resume tomorrow.
people should use the head-version
they should not. we try our best to stabilize before releasing.
BTW, I have a request for you. For a while we are stuck on writing an article for a journal. I could come up with the points but I am not getting time to write it down. You are an advanced nnn user. Would you be interested in writing the article and submitting to the journal? That would be a great help.
I am absolutely not an advanced nnn user (I've looked at it for maybe 2 days) and I have never written an article before but I sure would be willing to help in principle (if I can).
Let me see what you've got and I will think about it.
I've looked at it for maybe 2 days
In that case, it's a good hands-on session. ;)
I'll share the notes.
@annagrram I have added a line-item to redraw only affected lines on Up/Down key navigation. Could you take a look at it?
Sorry, I've got lost in all the activity over the night.
Can you please explain what do you mean by that?
Affected by what?
Currently in redraw() we refresh the whole view. It would be great if only for up and down arrows we can update the only 2 lines affected. The exceptions are at scrollock position where we move all entries up or down and the edges where we press up at top or down at bottom.
Got it.
I'll take a look at it.
Thank you!
only just figured out what this notification was for, I'm not talking about just sorting, I'm talking about those dividers between each section so for example in command line each time you switch from one group to another (including no group to group) You could plonk a description of the group and and line filled with = signs or something before starting the actual list, you can pull a description from the item your on when you determine you should switch
@awsdert a visual/textual example please.
I see peops mentioning about filters, just use regular expressions, example way to create it would be nnn --reg /bin/*
@joron, you'll have to wait for me to get back from work, only just started so can't focus on phone or think through an example
I think you are talking about visual changes in the listing. No plans to change the current listing style as it will affect areas like navigation, drawing etc.
I actually thought this was a command lone utility like gcc, anyways I imagine your drawing function begins & ends with something like glBegin & glEnd, just put those in wrapper functions called FrameOne and FrameEnd and add a new one called FrameNxt and return the correct frame from them, when in grouping mode it just ends the previous and starts a new drawing ctx or whatever and then the main function remains none the wiser
Well that's not how it's implemented. You can take a look at the code.
Also this has nothing to do with opengl. This a terminal file manager, we use ncurses (or rather ncursesw if we're being 100% correct).
I said something LIKE, meaning however your drawing function begins and ends a simple check in the middle is enough to call FrameNxt, also since it really is a command line utility as I thought, why not just use printf?, you only have to add a couple lines midway every now and then, anyways I'll take a look myself when I get the chance, however could someone point me in the right direction?
@KlzXS resuming the discussion on opening a list of files...
how about creating a temporary directory with softlinks to the list of files? All our issues would be gone. The user knows what he is doing and the file details will show the actual target.
Update: before you quit, simply remove the tmp directory.
@awsdert the drawing is done in redraw(). For navigation search "SEL_NEXT".
@awsdert
why not just use printf
because ncursesw is lean and provides features like mouse handling, resizing, coloring etc. without having to worry about tty details. We are not interested in rebuilding the wheel here.
Well that would mean you couldn't remove or rename files unless we implement special logic for it. Also it seems a bit wasteful to create all these links. Do you actually know if creating a bunch of links at once is a performance issue?
Well that would mean you couldn't remove or rename files
You will know when you are in this mode. So we will always use the target file (readlink()) for these operations.
Also it seems a bit wasteful to create all these links.
We will remove these when we quit. No it's not a performance problem. We already support softlink creation to selected files in bunch in nnn. Also I mentioned a tmp dir. Many people (like me) use tmpfs for that.
And trust me, this is much better than storing every path and manipulating it wherever we access path in browse() today.
A little feedback on filtering (in particular with regexes):
Most of the time the "standard" case-insensitive substring search is exactly what I want.
But sometimes I would like to search case-sensitive - this applies to both substring-search and regexes. At the moment everything is case-insensitve all the time with no way to change that.
Sometimes I want to filter based on a regex and then I have to restart nnn as I have to decide before I start nnn wether or not to use regexes. I would prefer a way where I could switch between substring-search and regex-matching without having to restart.
Sometimes it takes me a few tries to get the regex right. It would be extremely helpful if nnn would remember a few searches/patterns (or at least one) and would allow you to recall them (like eg vim does) so you could filter iteratively without having to type everything again.
I assume you want to stay as POSIXy as possible, but Perl compatible regexes are both more powerful and more convenient (and I am used to them). Just compare "\d" vs "[[:digit:]]".
There are PCRE-libraries for C, so in the longer run maybe it would be possible to be able to compile nnn with either the POSIX-library or the a PCRE-library?
At the moment everything is case-insensitive all the time with no way to change that.
It stays as it is. Most users wouldn't bother remembering the case in a filename.
I would prefer a way where I could switch between substring-search and regex-matching without having to restart.
That would mean another keybind... not happening. Close and open.
if nnn would remember a few searches/patterns (or at least one) and would allow you to recall them (like eg vim does) so you could filter iteratively without having to type everything again.
vim is not a great piece of software when it comes to memory management. I use lnav to check GBs of logs because vim is not fit for the job.
However, I think we can remember the last filter within the filter itself and show it at a particular keypress if the filter is empty.
so in the longer run maybe it would be possible to be able to compile nnn with either the POSIX-library or the a PCRE-library?
We just link to a standard C library (maybe glibc in your case) and it provides what you see. Can't add a new lib dep for this.
We just link to a standard C library (maybe glibc in your case) and it provides what you see. Can't add a new lib dep for this.
If you really want this, add the code within a macro and add a new Makefile target to compile with the PCRE library.
Hey guys, just quickly dropping by to report a small issue with reverse sort (R), it doesn't work on filtered directories.
/a<Esc>RActual: List is not reversed, but status bar shows R as if it is.
Expected: Either list is reversed (preferred), or R doesn't appear in status bar
P.S. Wow this is a long thread! 馃槃
I would prefer a way where I could switch between substring-search and regex-matching without having to restart.
I guess we can have key which when pressed in empty prompt switches between regex and string. What should the keybind be?
I think we can remember the last filter within the filter itself and show it at a particular keypress if the filter is empty.
And what should this keypress be?
@maximbaz commit c22bf87f3e23d39a2df939c9079aa193b8b3c336 should fix it.
@ghistes I think I have probable ways for all your requests:
At the moment everything is case-insensitive all the time with no way to change that
Maybe we can detect and enable case-sensitive matches when there's a capital in the string.
I would prefer a way where I could switch between substring-search and regex-matching without having to restart.
Suggest a keybind at empty prompt to do that.
if nnn would remember a few searches/patterns (or at least one)
I think we can remember the last filter within the filter itself and show it at a particular keypress if the filter is empty. Suggest a keypress.
We just link to a standard C library (maybe glibc in your case) and it provides what you see. Can't add a new lib dep for this.
If you really want this, add the code within a macro and add a new Makefile target to compile with the PCRE library. @maximbaz would you like to try this?
I have added line items for all of these.
For the filter keybinds. Use up arrow for previous, it's intuitive. Maybe use the left and right arrows to switch between regex and substring and maybe put something like s/r as a prompt and highlight the currently enabled one. Just and idea.
Currently the arrows work as they should in non-filter mode. Can't change the behaviour. Need control-codes.
Rolled at #427.