feat: add counter component to the header for displaying currently selected/yanked items

[Rolv-Apneseth]

No description provided.

[sxyazi]

Thank you for the PR!

I just want to add an API to get the number of selected files, but I realized an issue - currently, the selection state is specific to the directory, meaning it can only get the selection state of the current directory.

But it would make more sense to get all selected files for display. We will add support for selecting across directories in the future.

So I need to do some refactoring to modify it to a tab-specific global selection state. I'll continue reviewing this PR after the refactoring is done :)

[Rolv-Apneseth]

Ah I didn't catch that actually. Best of luck then, we can come back to this later

[og900aero]

Would it be possible to write not only the number of selected/yanked items, but also the size of all selected items?

[Rolv-Apneseth]

Would it be possible to write not only the number of selected/yanked items, but also the size of all selected items?

That may be better as a plugin or at least a separate feature, @sxyazi what do you think?

[sxyazi]

Yep it should work as a UI plugin and not included in this PR.

[Rolv-Apneseth]

Should be ready for you to review when you have the time @sxyazi , pretty small PR

[Rolv-Apneseth]

Yep those changes seem good. I do also like hiding the tab component if there's only one.

[sxyazi]

Alright, I think there are no more problems here, let us merge it!

[Brixy]

Thanks for the addition!

I noticed a tiny issue.

When you paste (y -> p) files anywhere the counter stays visible, which absolutely makes sense because you can paste to multiple locations using p without having to re-yank the original files.

Yet, when you move files (x -> p), the counter stays visible, although it is not possible to move the files again using p. In this case the counter should vanish, or it should be possible to move and then copy files using p multiple times.

(Tested with original config files.)

[sxyazi]

@Brixy Thanks for the reporting, should also be fixed in #690