nnn visually hangs when searching again without redrawing

[N-R-K]

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

• Operating System: Gentoo
• Desktop Environment: none (dwm)
• Terminal Emulator: st and xterm
• Shell: zsh v5.8
• Custom desktop opener (if applicable):
• Program options used: reproducable on vanilla
• Configuration options set: reproducable on vanilla
• Issue exists on nnn master

Exact steps to reproduce the issue

1. Search for a string /foo and then escape esc
2. Without redrawing, start searching (for something which exists the the dir but not on the current filter) again /bar

Pressing esc again gets it out of the hanged state.

P.S. v4.1.1 does not have this problem.

[jarun]

P.S. v4.1.1 does not have this problem.

Did you read the release notes?

ignore last pressed filter character when no matches

Pressing Esc does not clear a filter (read the docs). So searching for something which exists the the dir but not on the current filter will not change anything in the view and you won't see anything typed because there is no match (the char is ignored).

[jarun]

This is a change in behaviour. Now that you know it, live with it ;). It's better than typing characters even when there is not match.

[N-R-K]

This is a change in behaviour.

Hmm, I see. The experience here is a bit jarring. But if it's intended then I guess there's nothing to be done here.

[0xACE]

It's better than typing characters even when there is not match.

Personal build to the left. Master to the right.

trying to find a binary with pdf and zip in the file name.

Left hand side immediately tells me it doesnt exist.

Right hand side tells me to look through the list eventually realising that my key strokes were not accepted.

I'm not sure I agree with this behaviour... I mean on the right side i typed /pdf^[/zip and i would expect to hit backspace 3 times, but the UI is in a different state than my mental state...

Only benefit I see in master's current behaviour is in type-to-nav mode where you no longer have to erase on non-matches

Alas: I'm not saying revert it. I just want to mention that it feels like it is a deviation from the norms of UX

[jarun]

@0xACE you type and you don't see anything typed. Doesn't that indicate something went wrong?

I can revert this back. However, just confirm if you think it's difficult to get accustomed to the behaviour.

[jarun]

Or do you think it's better to have it only if type-to-nav mode is on? I would prefer to keep it consistent.

[jarun]

I think we should revert it... I can see why it won't feel natural to users.

[N-R-K]

you type and you don't see anything typed

I don't think people are staring at the bottom bar while searching/typing (I don't, and I'd assume most keyboard driven users are no different), so seeing the list clear up is a more natural and conventional behavior for when there is no match.

As for type-to-nav mode, I don't use it often to have any strong opinion on what the behavior there should be.

[jarun]

I don't think people are staring at the bottom bar while searching/typing (I don't, and I'd assume most keyboard driven users are no different)

And you don't see that the list isn't changing?

[N-R-K]

And you don't see that the list isn't changing?

Sure, but its not a conventional behaviour making the experience jarring.

Anyhow, I have the commit (3ef50f0) reverted on my system, so this is no longer going to be an issue for me.

[jarun]

I have reverted this as well. This does disrupt the workflow for the uninitiated.