ToDo list
jarun opened this issue · 45 comments
Rolled from #781.
Cooking
- allow plugins to clear selection (#884, #889, #917)
- do not clear selection on hovered file deletion
- resurrect
'c'urrent/'s'elprompt and option-u(#889) - more file/mime types supported in
preview-tui-ext - plugin
mtpmount- (un)mount MTP devices - plugin
cleanfilename- more shell-friendly file names - plugin
rsynccp- copy-paste with visual progress - replace
$HOMEby~in address bar - show current path in terminal title (#911)
- total links and inode number of hardlink in statusbar
- fix symlink to text file not opening in CLI editor (#890)
- fix symlink size shown as 0B in statusbar (#888)
- show symlink target in statusbar (#893)
- show correct disk free/total on macOS (#888)
- refactor printing entries in light/detail modes (#934)
Up for grabs
- a light colorscheme with
NNN_FCOLORS - update only current context data when saving session (#837)
- generate static binary for arm, aarch with releases using CI (#623)
- support predefined filters like bookmarks
- open new terminal window in spawned shell directory (#759)
For anything else please discuss in this thread.
Contribution guideline.
I've been thinking, it would be very nice if we could have separate documentation for every release in some form. Currently all documentation closely follows master, but many people just install whatever version is available in their repos. Then they try to follow the documentation provided here and run into issues. There have been several such issues raised in the past month, more than I feel there should be.
I'd like to know what you think of this and any ideas for nicely implementing and maintaining it.
Generally our release notes captures the highlights. it's in the CHANGELOG too.
I think what you are looking for is something like buku - https://buku.readthedocs.io/en/latest/?badge=latest
However, that needs moving our Wiki to readthedocs and auto-updating when we change the wiki. Not sure how seamless the integration is.
Yes, I guess what buku uses is something akin to what I was thinking of, but with more work.
I know there's a changelog, but do you really read the changelog before or after the documentation? I just wish it was a bit more accessible, that way it would hopefully lead to less people trying new things with old versions and then complaining when they don't work.
Also should we just implement some naive patch for persistent selection markers and then point people to that so they can compile it in themselves. That's also something I see repeated again and again.
It probably won't be very perfomant, there are going to be edge cases where it behaves in a way you didn't want it to, but you'll have it. Use at own risk.
That's also something I see repeated again and again.
Why not limit selection to the directory? No other FM delivers what we do, if people are still not OK, why not just provide the usual?
No, don't limit the current functionality. I was thinking of just a patch to add to nnn. There was talk about having some user submitted patches listed, but nothing ever came out of that as far as I know.
We can do that. Please see if you can come up with something.
Starting discussion on #919 here.
The PR implements a new config variable NNN_DCOLUMNS allowing to change the order of the detail columns in detail mode. This results in e.g. the following detail modes:
Old situation on master:
export NNN_DCOLUMNS=""
export NNN_DCOLUMNS="nsopt"
export NNN_DCOLUMNS=nsoPt"
When the name goes at the front and the length is 255 chars and it's a small terminal what happens to the other fields? Also, we like to keep config env variables minimum as well as checks in the code.
This case is not handled yet, currently it just refuses to open the detail view. So is there any hope of it merging if cases such as that are handled properly? Or is a new config variable already a blocking factor.
The whole thing is a blocking factor. :)
I do not see any issue with the current order though it is fixed. I understand your case for flexibility. However, from my exp I remember a smartphone giant who exposed too many internals (including channel selection) of SMS sending/receiving in the UI and no user could use it properly out of confusion. We have a fixed format and we are good as long as the information is correct.
Don't quite get your user confusion point. As you can see without NNN_DCOLUMNS set it will just fall back to the default order and display the same information as on master(except size left aligned instead of right aligned).
I was giving an example of what happens when you give too many options to the users. As long as we can't confirm all permutations and combinations in languages including Chinese it is difficult to figure. We have a tool that has undergone 4 years of development and users are accustomed to the current interface. Is it necessary to have this?
(except size left aligned instead of right aligned).
Speaking of, as a simple user and regardless of the things @jarun is mentioning, I find your changes interesting but I would prefer size to be right aligned. Units should always be right aligned in a table-like format in my opinion.
It would even be best if .0 could be added when there's no decimal so that the alignment is perfect, but this would probably clutter the view for limited benefits (i.e., helping with my alignment OCD and making size differences immediately evident, the latter may not be so negligible though).
I was giving an example of what happens when you give too many options to the users. As long as we can't confirm all permutations and combinations in languages including Chinese it is difficult to figure. We have a tool that has undergone 4 years of development and users are accustomed to the current interface. Is it necessary to have this?
And they will keep their accustomed interface if they don't define NNN_DCOLUMNS. Of course it's not necessary but I find the current detail view feels very wrong with the name as the last column. Especially when using icons.
Feel free to have a fork with the changes for yourself and others who prefer it.
It would even be best if
.0could be added when there's no decimal so that the alignment is perfect, but this would probably clutter the view for limited benefits (i.e., helping with my alignment OCD and making size differences immediately evident, the latter may not be so negligible though).
I do agree with you there, having the decimals lined up makes it more readable. I now have it looking like this:
Ha! I might be one of those using your fork then! But I'm afraid a fork might be difficult to maintain on the long term, it's already hard enough for me to just keep up with with updating my local installation of nnn with the quick progress of master. :>
Having details on the left is no issue for me though. I might even prefer it, but this is certainly because I don't use icons and I'm used to the output of ls -lah.
When the name goes at the front and the length is 255 chars and it's a small terminal what happens to the other fields? Also, we like to keep config env variables minimum as well as checks in the code.
Was able to fix this, export NNN_DCOLUMNS="nsoPt; touch aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa now results in:
The code quality probably isn't up to par since most of the alignment issues were fixed empirically so the logic is not clear in the code. However as far as I can tell no functional shortcomings remain, feel free to try it out here...
Any interest in a PR to use strftime() for time printing? Honours env variable TIME_STYLE used by GNU ls.
Implemented in luukvbaal@9ba1fbf, would have to be adjusted somewhat for upstream master.
BTW I don't see any issues with my detail column implementation:
Curious to know whether it works properly on other locales as well which @jarun was worried about.
Just curious, did you test it with n as the last column and long file names too?
Yeah works as it should on my end.
Feel free to have a fork with the changes for yourself and others who prefer it.
I'd rather not though. Preference can be defined in NNN_DCOLUMNS, that was the whole point.
It would be good to know what exactly keeps you from merging this feature. I don't want you to feel like I'm forcing this on you in your project so if you feel very strongly towards not merging this never mind... It's just that I'd rather not maintain a fork.
If increased binary size is the issue, how about another compile in option COLUMNORDER.
It would be good to know what exactly keeps you from merging this feature.
@luukvbaal I have already mentioned reasons I don't want this in nnn. It's a 100 line change littered around for non-essential functionality. I don't see any great usability improvement either. The uid:gid column can be variable sized also. This is probably the 3rd/4th time I am telling I don't want it in and you are still continuing the discussion. If that's not persuading, what is? Hopefully, now you will realize what I meant when I told you to start the discussion first before implementing any big change. It saves everyone's time. I will not be able to respond to any other argument regarding this feature. Thanks for your understanding.
There's something that I would like to have regarding the columns though. @KlzXS brought it up once. If we can merge the two print functions that would be great. The first would print the details of an entry and the second would print the filename. But once again, it's not a top priority for any of us.
Alright. Anyways the feature seemed essential to me hence why I implemented it...
For completeness: variable guid/filesize lengths were already considered and handled.
The uid:gid column can be variable sized also.
speaking of uid:gid; is there a way to only show a selection of files. Currently I have to comb through all the files (no biggie just want to make sure I have not missed the obvious).
Check plugin uidgid. Do something similar for selection.
Potentially controversial change to preview-tui-ext in #927, don't know if discussion is required?
Because of the current stage of the project we scrutinize a single extra line addition to the main program.
However, we are much more relaxed with scripts. 👍
@luukvbaal can you work on a light colorscheme for nnn using NNN_FCOLORS? The default one we have today is intended for the dark.
Never used a light theme so not sure how I would go about making one no.
No problem.
@toddyamakawa as well for the light colorscheme.
There's something that I would like to have regarding the columns though. @KlzXS brought it up once. If we can merge the two print functions that would be great. The first would print the details of an entry and the second would print the filename. But once again, it's not a top priority for any of us.
And I have just finished that. I'll submit a PR shortly.
There are small differences in printing the filename in two modes that are now easy to spot (checking the detailed flag). I don't know if they were intentional or not.
There are small differences in printing the filename in two modes that are now easy to spot (checking the detailed flag). I don't know if they were intentional or not.
Can you please add some more detail? What differences did you find?
It's actually just one difference in printing the soft link:
if (!detailed && g_state.oldcolor)
attrs |= A_DIM;
...
if (detailed || !g_state.oldcolor)
pair = (ent->flags & SYM_ORPHAN) ? C_ORP : C_LNK;
I think if we are in in 8-bit mode we still need to use A_DIM. What are we doing in 8-bit detail mode?
We don't change attrs in 8-bit detail mode. No A_DIM. There is always the link indicator.
That may be because we dim the details, I think we should also dim the symlinks to retain the visual semblance with the light mode.
And what about the difference in the color pair? It's 0 in the 8-bit light mode and not 0 in the detail mode.
Please check the PR and request your changes there.
Checking the PR and requesting changes there may not be possible because these were done long back and I don't remember every finer details there. So when you say there are differences I have to understand what they are from you and think accordingly.
Did the review. Please have a look.