[Feature request] Single instance mode

[rieje]

Just a simple request to force single instance (prevent multiple instances being launched). Sometimes multiple instances are launched accidentally (via hotkey, so not that uncommon) and it's not obvious this is the case since they overlap. When the newest instance ends, the other instances need to be dealt with and it's rare a user would want to launch multiple instances at once anyway.

Would prefer not to have to run another binary like pgrep.

[itshog]

I agree, this feature would be incredibly useful. I even argue that this could be the default behaviour, as having multiple instances of a menu program shown in the same position on the screen is more confusing than useful in my opinion.

[Earnestly]

A proper solution to this would be using sockets, much like everything else that implements "single instance mode"; but it really makes no sense to put such a limit on bemenu, despite the overlapping issue.

I do make use of this aspect which would otherwise require breaking up pipelines into multiple files and stagger execution.

However it's not difficult to create idempotent scripts, without using pgrep as you should never really attempt to manage processes (PIDs) that do not belong to your own (children). Such things are best used in an interactive capacity, much like htop and co. See https://mywiki.wooledge.org/BashFAQ/045

As an aside, to the overlapping issue, fzf implements this using the --sync flag which makes it possible to use: fzf ... | fzf --sync ... for multi-staged filters without having to stagger execution while storing intermediate state.

[merrittlj]

I will do more research into this, but I can ensure to add an option to disable the single-instance behavior(if it is default behavior). I appreciate the sources.

[merrittlj]

@Earnestly Are there any changes to bemenu that could help your workflow, such as more strictly determined behavior with multiple instances? Is this not a necessary concern at this time?

[Earnestly]

For my uses it's not all that important as any changes such as --sync would only be aesthetic at the moment. It may have mechanical need for other use cases but I'm not aware of those. The beauty of a pipeline is that each instance of bemenu is already initialised and waiting for input long before it comes, that and obviating the need for storing intermediate data outside of the pipe buffer.

I do agree with the issue of multi-instances causing trouble, but I don't think single instance is necessary in this case. Instead it would be nice if the initial instances would be refocused instead of just being left totally non-intractable. It is still possible to interact with these windows and refocus them using xdotool, e.g. xdotool search --class bemenu windowfocus.

In the long term as there is gradually more movement towards wayland I may end up placing more of my interaction in terminals, overloading them for launching commands instead of menus due to greater consistency across platforms.

[merrittlj]

@Earnestly Would forcing a single instance(with no flag) change your workflow? Do you require that we have a flag to enable the old multi-instance behavior?

We can explore better options with improving multiple instances in the future, but now we have to decide to keep or remove a flag for using the old multi-instance behavior.

[Earnestly]

I'd suggest changing bemenu to work with multiple instances, so that each menu gets focus when the last used instance closes and not have "single instance mode" at all. It's really not bemenu's fault that people don't write idempotent launchers.

I agree with @Cloudef that bemenu has far too many flags, and if bemenu was made single instance only, then I'd probably find some other menu or make my own instead of suggesting even more flags added.