Nnn: file selection bug

[nathanielevan]

Environment details (Put x in the checkbox along with the information)

[x] Operating System: Arch Linux
[x] Desktop Environment: bspwm, i3
[x] Terminal Emulator: alacritty, st, urxvt
[x] Shell: zsh
[ ] Custom desktop opener (if applicable):
[ ] Program options used:
[ ] Configuration options set:
[x] Issue exists on nnn master

Exact steps to reproduce the issue

I select a file by pressing space:

Then I visit a different directory, then go back to this directory, the + mark is gone:

The file itself is still selected, because I can move it to a different directory, e.g. ~/Documents:

But instead of moving the file, if I select the same file again, it becomes re-selected and the "select counter"(?) at the bottom of the screen increments:

And if I then move it to a different directory, I get this error:

The file still gets moved, though:

[KlzXS]

From the wiki:

If an already selected file doesn't have the + symbol before it (say, on a directory refresh or after navigating away and back to the dir), the selection toggle key will add it again.

This is the intended behavior.

[seifrox]

Hi,

I also stumbled over this behavior and find it not intuitive from a user's perspective.

So it is a good that it is properly documented! However, @KlzXS can you elaborate why this behavior is intended, and selected files are not just marked with the + again even after directory navigation/refresh or a redraw?

BR,
Alex

[jarun]

can you elaborate why this behavior is intended

Because of the theoretical maximum memory requirement to remember all selected files.
Please refer to commit 547d87bfc2caf276dd1bcb943677a0ca306c602d.

I also stumbled over this behavior and find it not intuitive from a user's perspective.

There are good file managers which limit selection within the same directory. Check out one of those.

nnn has many users on mid-range Android devices or boards like the Pi. Desktop users are not our primary concern. So we keep a tab on memory usage, performance and disk IO. If these are not your primary concern and a behaviour in nnn bothers you, you should try a different file manager that suits your needs.

[KlzXS]

Marking them again after re-entering of redrawing would require checking for each drawn file if it is in the selection. That is a lot of string comparisons and is not the cheapest of actions.

The same argument holds for why files can be selected multiple times. It's expensive to check files agains the selection.

There may be a way to create a fast way of checking using something like a hash table, but that would require extra memory usage. Which nnn tries to avaid if not necessary, since it also targets systems with low resources.

[KlzXS]

@jarun maybe this can be another user patch like the Miller columns, when that becomes a thing. What do you think?

[jarun]

maybe this

If you mean the patch, the memory usage is huge when it comes to supporting even 2 filesystems.

[KlzXS]

Maybe this

as in a general patch to solve this problem. Can be your hashbit attempt, can be something else.

Also help me understand "huge". If I'm reading the commit properly the required memory is around HASH_OCTETS << 3 bytes, which I think translates to 2MB, per fs. Now I understand that's some say 66% of memory it usually uses on my system, but I wouldn't consider that _huge_. After all the browser I'm viewing this in uses up about 1000 times more.

I'm not saying add it by default. I just think it might be worth including it next to Miller columns when/if that happens.

[jarun]

huge

That one was experimental. Inode number length in ext4 is 8 bytes. So to be accurate HASH_BITS would be 0xFFFFFFFFFFFFFFFF. So you need (2^256) and then comes multiple filesystems. Yes, we can try a more efficient polynomial hashing algo but I don't see the need for it given no other file manager does this today and:

• a user knows when he has selected something earlier
• we also show a count and selection mode indicator in the status bar
• we also have a provision for viewing/editing the current selection

I am familiar with the design choice of a smartphone UI where they exposed the SMS channels for the users to tweak easily. It was a disaster because users would make the config bad and complain it's the problem with the mobile. I see the same pattern here.

[KlzXS]

That one was experimental. Inode number length in ext4 is 8 bytes. So to be accurate HASH_BITS would be 0xFFFFFFFFFFFFFFFF.

Fair enough. There you have it folks, the reason.

[0xACE]

nnn has many users on mid-range Android devices or boards like the Pi. Desktop users are not our primary concern. So we keep a tab on memory usage, performance and disk IO. If these are not your primary concern and a behaviour in nnn bothers you, you should try a different file manager that suits your needs.

Chiming in to let you know: I consider the desktop to be one of the primary candidates for nnn. Though What is more important to me is that it will work on any of the machines I work with, so that my setup is consistent across multiple machines. Thus allowing my "usual" environment to be mobile via ssh/terminals... Infact I haven't launched my GUI file browser this year...

I will uninstall my GUI file browser when I get thumbnails and drag and drop working inside nnn (Both of which require modifying my terminal)