Rofi: Support custom entries with multi-select

[pigmonkey]

When using the -multi-select option, rofi does not allow selecting both a pre-populated entry and a custom entry.

Version

Version: 1.5.1-dirty (tags/1.5.1)

Configuration

https://gist.github.com/pigmonkey/51ea751d541877c60fdaf1a4e2075071

Launch Command

echo -e "foo\nbar\n" | rofi -dmenu -multi-select

Steps to reproduce

• Select "foo" with <Shift><Enter>
• Select a custom entry "baz" by typing baz<Enter>

What behaviour you see

• Rofi exits, returning foo

What behaviour you expect to see

• Rofi exits, returning foo and baz

[DaveDavenport]

The text ~entry~ box is not an entry, it is a filter key for the shown list.
Allowing the filter box to be selectable would be counter intuitive. I am not sure how this would work UI wise.

[pigmonkey]

If I launch rofi without the multi-select flag, I can select an entry that was not in the initial list:

$ echo -e "foo\nbar\n" | rofi -dmenu
# type: "baz<Enter>"
baz

If I launch rofi with the multi-select flag, I can still select an entry that was not in the initial list, as long as that is my only selection:

$ echo -e "foo\nbar\n" | rofi -dmenu -multi-select
# type: "baz<Enter>"
baz

It's only when I use -multi-select, and select a value in the list with <Shift><Enter>, and then input a custom value that this behavior breaks:

$ echo -e "foo\nbar\n" | rofi -dmenu -multi-select
# type: "foo<Shift><Enter>"
# clear text and type: "baz<Enter>"
foo

I think it is intuitive to allow the custom entry to be added as the final entry, ie with baz<Enter>.

The <Enter> key tells rofi to exit, so I don't think this adds any UI complexity. If there was support for selecting a custom entry without exiting (ie, baz<Shift><Enter>), then the custom entry would need to be added to the list with the selection indicator next to it, but for my use case, I'm satisfied with the custom entry being the final thing entered.

[DaveDavenport]

@carnager opinion on this?

[kevindirect]

I second @pigmonkey, especially because -no-custom already exists to disallow custom selections. The current behavior of '-multi-select' is what I would expect with '-multi-select -no-custom'. Doing what @pigmonkey suggests would make dmenu multi-select more exstensible.

[andrei-a-papou]

Agree with @kpatel28. Given -no-custom, the current behavior of -multi-select is a bit inconsistent, IMHO.