Nnn: Actions using the selection by default

[marioortizmanero]

Is your feature request related to a problem? Please describe.

When you select multiple files with the spacebar to - for example - delete them by pressing x, a prompt with 'c'urrent / 's'el appears. This also happens when batch-renaming or compressing files.

Describe the solution you'd like

I would say this prompt is pointless once you have multiple files already selected. It's the equivalent of selecting files in a GUI like Nautilus, and still having to choose between performing the removal with the selection or with all the files in the directory. It's quite obvious the user wants to do it with the selection.

How about this prompt is skipped in this case? Maybe I just don't need it in my own workflow; I would love to hear some opinions. It should skip to the regular confirmation step (rm -rf 3 file(s)?).

Additional context

Consider contributing

I would love to help with coding this feature but I'm not sure how hard it would be, btw.

[jarun]

I would say this prompt is pointless once you have multiple files already selected.

How about the case where you select multiple files and when you reach the destination directory you see you have a file there and you want to remove it before copying/moving the selection than after (that way you don't have to remember the name of the file you want to delete anyway).

The reason you think it's pointless is you haven't found the correct use-case yet or are too organized.

In any case, even when multiple files are selected, the keybinds x and ^X can be used to delete the current file or the selection. So it stays so the user can always have the choice.

[marioortizmanero]

Okay, didn't think of that case. Other actions like compressing still don't make sense to me in that way. Anyway, I would have all of them act the same for consistency, thanks for the quick reply.

[jarun]

Thanks to a very well-organized code, if you don't really care for any of the cases, use the following patch:

diff --git a/src/nnn.c b/src/nnn.c
index 3e6e63a..90cf7e3 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -846,12 +846,6 @@ static int get_input(const char *prompt)

 static int get_cur_or_sel(void)
 {
-       if (selbufpos && ndents) {
-               int choice = get_input(messages[MSG_CUR_SEL_OPTS]);
-
-               return ((choice == 'c' || choice == 's') ? choice : 0);
-       }
-
        if (selbufpos)
                return 's';

[jarun]

@marioortizmanero I have implemented the enhancement at commit 4b4bf6cca55e7f6710113e36c5ff8f776ca045a2 with option -u. Please confirm it works as you expect.

[marioortizmanero]

Wow, it's perfect! I've tried it and it's exactly what I was looking for :)

[jarun]

Cool!

[Kabouik]

Speaking of this, I always thought that "current" is ambiguous. It could equally apply to the (current) selection, the files selected in the current folder and not those in other folders, just the hovered file, or all files in the current folder. Even if it's in the manual, multiple interpretations for something that may be followed by rm -rf seems dangerous. Am I the only one finding "current" ambiguous?

[jarun]

I think we should change it to hovered for more clarity.

[jarun]

But there will be a catch in case of batch rename where we would still have to pick all the files in the current directory when user selects hovered.

[Kabouik]

I was about to reply that "hovered" would be perfect and consistent with the wording used elsewhere in nnn, but I'm not sure how to deal with the conflict you just raised.

[jarun]

Yes, and I do not want a different question/handling for a single case. I think we are fine with what we have.

[jarun]

I missed the fact the you are much newer to nnn than many users who are already accustomed to these. Let's not go back in time and try to fix things no one bothers about anymore.

[Kabouik]

The fact that "current" means two different things depending if the user is about to rename (all files in folder) or do any other action (just hovered file) shows that having the same system and wording is misleading though, but I understand your point too.

[jarun]

The fact that "current" means two different things depending if the user is about to rename (all files in folder) or do any other action (just hovered file) shows that having the same system and wording is misleading

Most words in every language has different meanings based on the context and people are used to that.

misleading

What's misleading here? You are pressing a key to _batch_ rename and you expect 1 file to be picked for the operation?

[Kabouik]

I am sorry if this sounded bad, I did not mean to upset you (at all). I said above what sounded ambiguous to me and I explained why. However I cannot exclude that it might be clear to everyone else, I even asked this very question. If it is clear, then there's no issue.

To me "hovered" would be unequivocal and more consistent, even for experienced users, but I fully agree with you that it cannot work with the behaviour of batch rename unless this action uses a different confirmation prompt, which is not desirable. So nevermind, this was just a mere comment before thinking about batch rename.

[jarun]

I am sorry if this sounded bad, I did not mean to upset you

I'm not upset. When you use terms like _ambiguous_ or _misleading_ you have to back it up with reason.

Also, as a collaborator when you evaluate a software you have to look beyond personal interpretations (the _to me_ part). It doesn't matter what it appears to you or me. There are factors like code maintenance and uniform workflows. In addition, nnn is not for users who need to be spoonfed things and it's not for devs who add a new fixed string and condition check for every trivial thing and increase the code size without thinking of consequences. There's a distro released yesterday the core version of which comes in 13MB (with both legacy BIOS and UEFI support) and they took a note that they have nnn shipped in it. That's what nnn stands for. The last section of the audience we care about is desktop users accustomed to bloatware which assume they have infinite memory and processor speed available to them.

[jarun]

The strategy may sound alien to you because it's a lost art. But the thing is, running unnecessary stuff in your processor is a wastage of power and memory, printing longer strings takes time. And these things become evident when you work remotely over a trippy SSH connection or a old monitor (even 8-bit ttys on modern computers), one of the initial Pi offerings or Termux on a cheap Android phone.

And believe it or not, children in the third world consider themselves lucky if they can access any of the constrained resources I mentioned above. In Africa probably 90% of the primary schools don't even have a computer. I am much more concerned about that constrained/ignored next generation of ours than users who can't patch a software despite owning the latest of devices and high-speed internet. Because I believe if they get the chance to learn, those kids will be more than eager to do that part by themselves. I know I did.

So when I write my utilities, I write out of limitless love for them. Not for myself, not for you.

[jarun]

BTW, you can ignore the last part. I am kind of tired of users asking for patches for the most trivial things when all they need to do is to change the part they want (and we share the patches as well), install gcc/clang, and run make with O_NORL.

[Kabouik]

I'm not upset. When you use terms like ambiguous or misleading you have to back it up with reason.

I thought I did: "current" can be several things in this context, as opposed to "hovered" used in other places. Also, nnn is frugal on context words (which is good, we don't need any clutter), so when "hovered" is used elsewhere (wiki, plugins, not sure about nnn itself), a reasonable asumption is that any use of another word describes a different action. Here, "current" is favoured not because it is different - it equals "hovered" for all actions but one - but because batch rename actually applies either on selection or on all files. The exception makes the use of a different word in all contexts, which I find counter-intuitive for a software otherwise not swapping words easily to keep things simple, even if we consider only experienced users.

But you are absolutely right that "hovered" cannot work here since batch rename uses the same selection prompt. I didn't think about it, so end of story, I'm 100% fine with not changing anything. Again, I was thinking replacing "current" with "hovered" plain and simple would work. It's only later that I understood why it cannot. Code apart, batch rename could use "all/selection" vs "hovered/selection" for other actions, or even a triple choice to cover all cases in one prompt with "hovered/selection/all", where batch rename on "hovered" would just call regular rename. That doesn't mean it's doable easily or even worth the effort and extra code. Keeping the code simple is a perfectly good argument.

Of course I agree with nnn's rationale and I don't want to complicate it, no question about what your second paragraph implies. It would be a stretch to assume I wanted to complicate nnn by using "hovered" here. I initially just asked if others thought "current" could be improved. I'd rather stop the discussion here now, I realize I am wasting your time and I'm not too comfortable with the lengthy apologetic explanations to say in the end that I agree but just didn't see the batch rename issue coming.

[jarun]

Nothing to apologise for. And I wasn't upset either. But I wanted to explain in detail why I think a lot before adding a byte. ;)

And you guys (collabs) should be aware of these as the future of all my utilities is with you.

That and users are coming back with very mundane stuff with the growing popularity, as if it's just another desktopware.

[Kabouik]

Related: is there an IRC channel or any other place to discuss nnn besides Github issues? Not a support chat of course, but just a place to check first and quickly ask collaborators when unsure if the question/suggestion/suspected bug is worth an issue, without sending a notification to all subscribers on Github.

[jarun]

Gitter: https://gitter.im/jarun/nnn

[marioortizmanero]

The Gitter link should be mentioned somewhere in the wiki or in the README (if you're actually interested in using it). There are no mentions of it in any of them currently. I think it would specially fit in a CONTRIBUTIONS.md. The repo currently doesn't have one and it helps new developers, as it was suggested here: https://github.com/jarun/nnn/pull/638

[jarun]

@marioortizmanero can you raise a PR for the CONTRIBUTIONS.md?

[marioortizmanero]

Will do.