GNU bug report logs - #32731
26.1.50; Ibuffer filter by mode: Handle >1 mode names

Previous Next

Full log

Message #17 received at 32731 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Tino Calancha <tino.calancha <at> gmail.com>
Cc: 32731 <at> debbugs.gnu.org
Subject: Re: bug#32731: 26.1.50; Ibuffer filter by mode: Handle >1 mode names
Date: Thu, 13 Sep 2018 19:39:17 -0400

Tino Calancha <tino.calancha <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.