Running an arbitrary command panics

[WhyNotHugo]

Running an arbitrary command (e.g.: firefox --no-remote) panics:

$ yofi
[type `firefox --no-remote` and hit enter]
thread 'main' panicked at 'Internal error: selected_item overflow', src/state.rs:28:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[l4l]

The search list contains no items, right? If so that an indented behavior then, though panic message might definitely be improved. What is your expectation for that case?

[WhyNotHugo]

The search list contains no items, right?

Yes, that's correct.

What is your expectation for that case?

I'd expect for the typed-in command to be executed (e.g.: firefox --no-remote).

[l4l]

Yeah, I see, a copy-pasted answer from reddit:

That's a little bit messy, because sometimes you want to launch an app that contains multiple words and another time an app with some arguments. Personally don't really like the implicit way of handling that (e.g. as it done in rofi), so I'd like to consider an explicit argument separation via special characters, take a look at #8.

Besides, there are 2 related modes: apps (searches for desktop files, that one is default) and binapps (searches for executable files). Perhaps for the second one there's no need for a special separator (as usually executable files have no spaces in file name) indeed.

P.S. the error message is a little bit better now: bc32e17

[WhyNotHugo]

Hmm, I see.

However, this does become a hard dealbreaker -- since it is impossible to run firefox --no-remote. Using the binapps mode works, but that means I'd not longer be able to run desktop files (e.g.: the default).

Most of the time, I do want desktop files though. And having two separate launchers is a bit too much complexity for me.

Maybe rather than panic! if there are no results, try to run exactly what's typed into the input field? It seems like a sensible default with no apparent drawbacks.

[l4l]

Using the binapps mode works

Keep in mind, it was only my thoughts so far, binapps mode can only launch exact binaries, no arguments are supported yet.

I agree there's no sense to pass arguments only for binapps but not for apps mode. I meant that for apps I would rather consider using it with a special separator, i.e. firefox !! --no-remote, thus both apps "Firefox" and "Firefox --No-Remote" (this one probably unrealistic, but for some cases still possible) can be launched. That's however won't work with apps that contain "!!" in their name, but I hope that's a negligible case and easy to make configurable. May that work for you?

Maybe rather than panic! if there are no results, try to run exactly what's typed into the input field? It seems like a sensible default with no apparent drawbacks.

Yeah, that sounds like a meaningful fallback. However, keep in mind there are still problems with this:

1. Search results may prohibit you from calling some applications (i.e. if command with args match some other app name as it's with "Firefox --No-Remote"), so it's not a generic solution.
2. Fuzzy search is not available (i.e. you cannot type ffx --no-remote and expect to launch firefox, which most of the time sucks).
3. Application name does not necessarily match an executable name. For firefox it's fine (though must be in lower-case), but, as an example, that doesn't work for PulseAudio Volume Control, thus search results are useless for that case.
4. Currently, there's no way to distinguish a "non-existent" binary (e.g. not installed, not found in $PATH, etc), or program-level error (e.g. invalid arguments). From my point of view that's quite a nasty user-experience. First case mostly (i.e. with consistent desktop files) is impossible for both of discussed modes.