Doesn't cover all cases inclusively. For some filenames the difference may be in the middle. There's always <kbd>f</kbd>/<kbd>^F</kbd> for file details. Just leave it be.

Following discussion from #267 I do think showing the the last characters of the file name should be prioritized in the case of file names longer than the name column. I was wondering if we should consider changing the unescape() function to return something like abcmnopqrst.txt or abc...pqrst.txt for abcdefghijklmnopqrst.txt.

Thank you 😊️

Get well soon!

@jarun Due to illness, I don't feel well, so now I rarely reply to messages. Excuse me. I will definitely add a light theme.

The dancing columns are a bit of an issue for me too. Also showing the end of long file names is crucial for me, I need to see extensions and also colleagues tend to append the date and their initials at the end of files they revised, so only the last characters allow distinguishing files.

What do you think about not ditching .0 in round file sizes to keep better number alignments (and easier size comparisons) @jarun?

I suggest keeping your personal changes in a git branch. Then you can easily generate a diff with upstream (to apply with patch) with something like git diff <upstream>/master <branch>.

This PKGBUILD(beware this uses my fork as a base, adapt for upstream) automates the process further using the github diff url. Using this PKGBUILD updating for me amounts to makepkg -i on Arch Linux. I'm sure the same patching method could be applied to other distro's build scripts, or even a distro-agnostic build script.

Thanks, I'lll investigate this route. This will be a good git practice too, because I can't do much without reading the doc or stackoverflow besides clone/pull/add/commit/push!

Settled with reverse. Try commit 7acc9196d5d7ce98446d23531ccf2a171ded7187.

@dymn

Is it possible to highlight the status of the selection in the status bar, and the "+" signs themselves next to the files, in some bright color so that they draw attention to themselves?

We are showing those in bold in commit 4727b3baa8acb99f0a59ee8f834ea68270aeb199.

We can't use another color because there's no color that would work both with dark and light terminal colorschemes.

My representation shows more of the name in case the largest size entry is smaller than the fixed width of the size column.

Yeah if you consider the "dancing" an issue that can't be avoided unfortunately when optimizing for screen estate. It only happens when holding down <kbd>J/K</kbd> in a large directory however and my eyes are focused on the name(which is static) when scrolling so I don't see it as an issue.

If anything my patch can show more

I think it will be the same if we fill to the last entry with the same columns in detail mode. However, now I remember we had the issue of dancing columns vs. the columns too far away.

@jarun if you hadn't noticed this is a really old issue, I just posted here for anyone who might come across it if they're interested in this feature.

When you have a long filename, it's something you want to see (as much as possible). What if there are 5 files with the same long prefix and only the last character is a changing index. We cannot drop that functionality.

That functionality is not present on upstream though is it? The name is cut off at the end, same as on upstream. If anything my patch can show more of the file names in such a case due to optimizing the size column width to the longest entry instead of a fixed width.

The default NNN_COLORS and NNN_FCOLORS (configuration details) are suitable for dark backgrounds.

It would be great to have a default light colorscheme for users who are accustomed to lighter terminal colors.

If you have a suggestion, please share the config values, the light terminal theme name with an image in this thread.

A good start may be a popular terminal theme like Solarized Light.

@akimdi can you add it here? https://github.com/jarun/nnn/wiki/Themes

I am closing this thread as there is no light colorscheme in a month.