Pressing <kb-accept-entry> with no input and require-input enabled

[elamperti]

If require-input is set to true, executing rofi (I'm trying with dmenu mode) and pressing enter (or whichever kb-accept-entry you set) with no input will launch the first item of the list. I'd expect that, if require-input is enabled, it shouldn't be possible to accept an invisible entry (i.e. cancel).

As it is now, it seems to be behaving only as a cosmetic toggle for the listview and produces a confusing result.

Is this the intended behavior? Shouldn't it consider require-input? (if not, any idea on how to cancel if there's no input?)

[DaveDavenport]

it is only cosmetic.

hit your kb-cancel keybinding.

[elamperti]

I know I can use kb-cancel, but sometimes one may accidentally use kb-accept with no input and, when that happens with nothing visible in the list, it would make a lot of sense to behave as if kb-cancel was hit from a UX perspective.

Some references from elsewhere:

• MacOS spotlight doesn't launch anything when there's no query and enter is pressed (stays open)
• Spotify does nothing
• Google, Bing and Amazon stay on their home pages
• GitHub only redirects to their search page

At the very least, I'd expect it to stay open but not to launch the first (hidden) item of the list.

Would you accept a PR to either follow this behavior or at least have it as an option?

[DaveDavenport]

I am not happy with this.. I should not have added the require-input option..
Rofi is a filter, not a searcher, therefor not relevant to the above comparison.

[DaveDavenport]

clarified the manpage, to indicates this only hides the view but does not block interaction.

[elamperti]

Rofi is a filter, not a searcher, therefor not relevant to the above comparison.

I get it! But in practice it's being used (as the repo description says) as an application launcher and dmenu replacement -- I'd say it's comparable at least with spotlight (or the Windows start menu search).

As a long-time rofi user, I'm thankful require-input is there! 🙂 I don't think it's a problem but the opposite: it's a helpful feature that benefits the community.

I should have guessed it's just cosmetic as it's part of the listview styling and not a proper configuration option, but alas, in practice the problem remains for me.

---

I've opened a PR (as WIP) so you -or anyone else that may have interest in having this behavior- can take a look at my suggested changes.

---

A note regarding your doc changes: if require_input is enabled, the list will not respond to normal interaction: although listview_nav_* will be called, there's a check in listview_set_num_elements() that results in the selection remaining unchanged (because many checks rely on lv->req_elements), so it will always select the first element.

Thanks for your time!

[DaveDavenport]

Yes, the navigation won't work. Ill update the documentation.

[pvgoran]

@DaveDavenport I second the request for an ability to disable launching the invisible first item, for the same reason as the topic opener: I don't want to run some semi-random command if I press Enter with empty input. (For added context: I'm migrating from XFCE's Verve panel plugin, which doesn't hide when I press Esc, but does hide when I press Enter with empty input. So I have a habit of pressing Enter when decide I don't want to run anything after I press the launcher shortcut.)

The earlier issue about this, #742, contained a link to the WIP/test commit 8492543, which introduced the search-mode option. However, this commit didn't make it to the code base, and support for require-input was added instead. Can we have search-mode in addition to (or maybe instead of) require-input? :)