ToDo list #881

jarun · 2021-03-15T19:19:41Z

Rolled from #781.

Cooking

Up for grabs

a light colorscheme with NNN_FCOLORS
update only current context data when saving session (Storable contexts as the missing link halfway between bookmarks and sessions? #837)
generate static binary for arm, aarch with releases using CI (arm and aarch releases with statically linked dependencies #623)
support predefined filters like bookmarks
open new terminal window in spawned shell directory (Spawned shell (!) with kitty (--cwd=current) #759)

For anything else please discuss in this thread.

Contribution guideline.

The text was updated successfully, but these errors were encountered:

KlzXS · 2021-03-15T20:04:47Z

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.

jarun · 2021-03-15T20:21:28Z

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.

KlzXS · 2021-03-15T20:51:03Z

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.

KlzXS · 2021-03-15T20:56:26Z

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.

jarun · 2021-03-15T21:12:52Z

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?

KlzXS · 2021-03-15T21:43:23Z

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.

jarun · 2021-03-16T02:05:52Z

We can do that. Please see if you can come up with something.

luukvbaal · 2021-03-26T13:56:33Z

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"

jarun · 2021-03-26T14:00:40Z

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.

luukvbaal · 2021-03-26T14:15:09Z

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.

jarun · 2021-03-26T14:19:25Z

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.

luukvbaal · 2021-03-26T14:27:43Z

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

jarun · 2021-03-26T14:32:00Z

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?

Kabouik · 2021-03-26T14:32:32Z

(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).

luukvbaal · 2021-03-26T14:39:30Z

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.

jarun · 2021-03-26T14:40:33Z

Feel free to have a fork with the changes for yourself and others who prefer it.

luukvbaal · 2021-03-26T18:04:52Z

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 do agree with you there, having the decimals lined up makes it more readable. I now have it looking like this:

Kabouik · 2021-03-26T19:54:21Z

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.

luukvbaal · 2021-03-27T00:35:42Z

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...

luukvbaal · 2021-03-27T10:43:47Z

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.

luukvbaal · 2021-03-27T11:08:08Z

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.

Kabouik · 2021-03-27T11:29:48Z

Just curious, did you test it with n as the last column and long file names too?

luukvbaal · 2021-03-27T11:31:47Z

Yeah works as it should on my end.

luukvbaal · 2021-03-27T13:14:39Z

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.

jarun · 2021-03-27T14:17:11Z

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.

luukvbaal · 2021-03-27T15:12:05Z

Alright. Anyways the feature seemed essential to me hence why I implemented it...

For completeness: variable guid/filesize lengths were already considered and handled.

ralphee · 2021-03-27T19:13:22Z

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

jarun · 2021-03-27T19:17:46Z

Check plugin uidgid. Do something similar for selection.

luukvbaal · 2021-03-28T18:57:56Z

Potentially controversial change to preview-tui-ext in #927, don't know if discussion is required?

jarun · 2021-03-29T02:23:14Z

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. 👍

jarun · 2021-03-29T02:49:46Z

@luukvbaal can you work on a light colorscheme for nnn using NNN_FCOLORS? The default one we have today is intended for the dark.

luukvbaal · 2021-03-29T02:57:47Z

Never used a light theme so not sure how I would go about making one no.

jarun · 2021-03-29T02:59:00Z

No problem.

jarun · 2021-03-30T03:24:48Z

@0xACE I have taken care of the plugin framework changes to explicitly clear the sel F438 ection.

@0xACE @KlzXS @Kabouik @leovilok @snide would it be possible to work on a light colorscheme for nnn?

jarun · 2021-03-30T03:44:36Z

@toddyamakawa as well for the light colorscheme.

exoton · 2021-04-04T17:36:17Z

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.

jarun · 2021-04-04T18:26:04Z

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?

exoton · 2021-04-04T18:36:38Z

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;

jarun · 2021-04-04T18:48:57Z

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?

exoton · 2021-04-04T18:54:44Z

We don't change attrs in 8-bit detail mode. No A_DIM. There is always the link indicator.

jarun · 2021-04-04T19:02:06Z

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.

exoton · 2021-04-04T19:13:14Z

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.

jarun · 2021-04-05T01:43:36Z

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.

jarun · 2021-04-05T03:05:25Z

Did the review. Please have a look.

jarun · 2021-04-05T19:31:16Z

Rolled at #935.

jarun added the bug label Mar 15, 2021

jarun mentioned this issue Mar 15, 2021

ToDo list #781

Closed

21 tasks

jarun added planning and removed bug labels Mar 16, 2021

jarun closed this as completed Apr 5, 2021

Repository owner locked and limited conversation to collaborators Apr 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ToDo list #881

ToDo list #881

ToDo list #881

ToDo list #881

Comments

Cooking

Up for grabs