bug#32731: 26.1.50; Ibuffer filter by mode: Handle >1 mode names

[Noam Postavsky]

Tino Calancha <tino.calancha@gmail.com> writes:

>> Maybe it's simpler to construct the filter directly? As in:
>>
>>   (push `(or ,@(mapcar (lambda (m) `(used-mode . ,m)) modes))
>>         ibuffer-filtering-qualifiers)
>>   (ibuffer-update nil t)
> I tried this way and I see 2 nits:
> 1) With just one mode you still get superflous `or'
>    [OR [major mode in use: mode1]]
>
> 2) Also, with just one mode, we miss the printout message
>    with the description:
> "Filter by major mode in use added:  mode1"

Yeah, we need special cases for lists of zero and one modes.

> Less important but `define-ibuffer-filter' performs some checks
> (there is a `condition-case').

The condition-case thing is in a lambda form which goes into
ibuffer-filtering-alist, so I don't think there is a need to explicitly
invoke it when constructing a filter of an existing type.

> Next one just use `completing-read-multiple' (keeps calling
> `'ibuffer-filter-by-used-mode'); I prefer this one:

I would be okay if it was just a matter of repeated ibuffer-filter-*
calls, but the fact that it produces error messages which then need to
be hidden makes it unacceptable, IMO.