return code when cancelled should not be 0

[Pierric82]

Hi,

I've adopted rofimoji recently. On my setup (fairly minimalist wayland desktop with hyprland), the direct input action works in some apps (terminal) but not others (vivaldi browser, running as wayland native app). So I've set up a shortcut to use the clipboard output instead, paste and then remove the clipboard element:

rofimoji -a copy && hyprctl dispatch sendshortcut CTRL,v,activewindow && cliphist list | head -n1 | cliphist delete

This works nicely when I do select an emoji. But if I hit escape to cancel, rofimoji returns 0 as error code, so the entire sequence still happens instead of stopping like one would expect, and I end up pasting something else, and deleting something from my clipboard history.

All of this to say: I think it would make sense for rofimoji to return a non-zero code when the menu is exited without a character being selected.

[fdw]

You know that there's an action clipboard that does something very similar?

Also, the question for me is: Is it an error or a normal exit when you cancel rofimoji? So far, I've thought that it's not unusual or an error, so the return code should indicate a normal exit. Is there a standard behavior?

[Pierric82]

You know that there's an action clipboard that does something very similar?

For some reason, no, I didn't try that. Thanks for pointing it out. I did try now. I'm getting erratic behaviour, probably due to the interference with cliphist, which monitors the clipboard to save the history. The pasting in itself works. I did get the clipboard correctly restored once, but in general, the clipboard is empty, rather than restored, after the operation. And in nearly every case, cliphist captures the copied character into the clipboard history, which I'm trying to avoid with my approach (by deleting it right after). So in the end, the issue of having to tell cliphist to clear the last entry remains, and that works only to the extent that I can know if the copying operation was in fact cancelled. In other words, I run into the same issue with cliphist with both copy and clipboard.

Also, the question for me is: Is it an error or a normal exit when you cancel rofimoji? So far, I've thought that it's not unusual or an error, so the return code should indicate a normal exit. Is there a standard behavior?

I admit it can be somewhat subjective. For me, the core value of the return codes is to allow such piping as I'm trying to do, i.e. '0' means "all went as planned, continue with your pipeline". I think an interruption by the user, while not a technical error, still warrants a dedicated return code to say "we didn't go ahead with the copying/insertion of an emoji". To me this fits the Unix return codes philosophy in a logical way.
As for standards, I could find this page which does not shed a definite light on this, but I would highlight that the wording says the exit code is used to pass some information to the caller - it's not worded in terms of failures, errors, etc., just high-level information. Combine this with the piping scenario, and that leaves me convinced that "aborted by user" should be a dedicated non-zero code.

Hope that makes sense!

[fdw]

So, first, I did some research and while there is nothing definite, I was convinced to return 1 when the user cancelled. It's already on main.

I'm getting erratic behaviour, probably due to the interference with cliphist, which monitors the clipboard to save the history.

I'm also using cliphist, and I'm not often using clipboard, but I have not yet ran into any error: cliphist does catch it, but that's to be expected.

the clipboard is empty, rather than restored, after the operation.

I need to look further into this, but it seems wl-paste will only return the contents once, and an empty string thereafter, making it appear as if the clipboard is empty. Restoring nothing, ie an empty clipboard, is not that helpful in my opinion.

[Pierric82]

So, first, I did some research and while there is nothing definite, I was convinced to return 1 when the user cancelled. It's already on main.

Awesome! Thank you. I'll try it when I get a chance, but can already mark the ticket as closed.

I'm also using cliphist, and I'm not often using clipboard, but I have not yet ran into any error: cliphist does catch it, but that's to be expected.

To clarify I wasn't implying this "interference" was a bug. Rather, it doesn't fit the way I'd like things to work, that is, I don't want my clipboard history to be filled with emojis that I've inserted through rofimoji. But indeed, except maybe for that one time it didn't happen, cliphist did its job.

I need to look further into this, but it seems wl-paste will only return the contents once, and an empty string thereafter, making it appear as if the clipboard is empty. Restoring nothing, ie an empty clipboard, is not that helpful in my opinion.

I'm not sure I follow, though I think I agree on that last statement.