I really don't like the addition of an rm -rf keybind regardless of NNN_TRASH

[stelcodes]

With #1811, the keybind X will rm -rf files regardless of whether NNN_TRASH is set. I really don't like this new behavior. I use NNN_TRASH precisely because it's very difficult to accidentally rm -rf files. I don't want to worry about accidentally pressing it if I hit the capslock key mistakenly. It's frustrating that there didn't even seem to be any demand for this feature besides from the person who implemented it. Most users probably have no idea this was merged. When the next release finally comes, I'm sure I won't be the only one disappointed. I'll probably stick to v4.9 if it doesn't get reverted. Does anyone else feel similarly?

[N-R-K]

there didn't even seem to be any demand for this feature

I often need to create temporary files for testing and want them to be removed completely; not moved to trash-bin.

Having an option to bypass trash isn't a niche case and we generally don't merge things if it's just one person with a niche usecase.

I'll probably stick to v4.9 if it doesn't get reverted

You can simply remove the binding in src/nnn.h for your local build.

[stelcodes]

That use case makes sense, but from my perspective the greatest benefit of NNN_TRASH is the strong guards it provides against accidental data loss. That's my main point. Having both trash and rm -rf available is convenient. But for me, having a guard against accidental data loss is a much more valuable feature.

I definitely can (and probably will) stop using my distro's binary cache, create a patch, compile nnn on all my machines, and keep maintaining that patch for subsequent nnn versions. That's a feasible solution but it's much more work than writing a little bash script plugin that runs rm -rf on the nnn selection. I think we just disagree on the value of the data loss guardrails provided by NNN_TRASH. It was one of my favorite features about nnn and I'm disappointed to see it suddenly removed.

[elandorr]

I agree with @stelcodes.

You can simply remove the binding in src/nnn.h for your local build.

Terrible way to go about it. nnn has become a standard tool, you don't keep custom builds for each of the dozens if not hundreds of standard tools you need. nnn is even in standard repos now, which is nice.

It's not feasible nor even possible to build your own everywhere either.

This should definitely be opt-in, as everything in general. A flag or a config file if needs be.

An option that can and realistically will cause accidental data loss is terrible in general.

I often need to create temporary files for testing and want them to be removed completely; not moved to trash-bin.

Then create a script for your specific use-case that cleans up in whatever interval you need. Or just run a bash loop one liner.

[KlzXS]

First, while I get your concern I also think this feature should exist. Just having trashing enabled shouldn't prevent you from permanently deleting files. Every single major file manager that I know off has some way to permanently delete a file, usually Shift+Del followed by a prompt as opposed to not needing a prompt when trashing. nnn should too. Being able to permanently delete things is a requirement for a system, the ability to trash, although pretty much universal, is an optinal luxury.

With that said, would a better prompt make you more comfortable with this feature?

Second, it is nice that nnn is being included as a standard tool and I'm happy to see that. But keep in mind that that was not the goal when development started. It was never meant to be the new sliced bread of file managers. It was supposed to be, just as it is still, a lightweight, minimal bloat, suckless-like program, says so on the wiki. And in keeping with that almost all configuration is compile time.

With that said, runtime configuration has been requested many times and nnn has a few patches promoted on the repo. A patch implementing such a feature is more than welcome, but if you don't want to do it yourself you'll just have to wait for someone else who does.

[stelcodes]

@KlzXS Just want to give my 2 cents.

Realistically, no version of the prompt will be effective in preventing accidental data loss. Trashing has a prompt too and the odds that an NNN_TRASH user will just use muscle memory to confirm deletion after accidentally using uppercase X is very high.

Permanent deletion is necessary of course, but I think we disagree on the value of the guardrails provided by NNN_TRASH.

I will most likely write a patch if no one else beats me to it when the next version gets released.

[izmyname]

I think hiding the option behind an env var (NNN_DELETE) with the default value of 0 would be a good solution, fitting the overall nnn configuration style. I, myself, like the option to permanently delete files regardless of NNN_TRASH value, but I also understand, why some people don't like it.

[vorboyvo]

Part of my issue with it is that it's neither able to be disabled (through env var, keeping with the configless setup) nor is it a key combination that's hard to hit by accident. i misinput fairly often (for example, inputting to the wrong terminal window when trying to do text editing) and shift+X is not a difficult keybind to hit on accident. anything as destructive should be a keybind that requires it to be pressed quite deliberately

[jarun]

There are contradictory user experiences and requests on this one. We are supporting both.