Re: [PATCH v3] Allow applying filters to summary consecutively

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: andrea.monaco@autistici.org, rpluim@gmail.com, emacs-devel@gnu.org
> Date: Fri, 11 Nov 2022 22:35:54 -0500
> 
>   > That's okay, thanks.  But it's only the beginning of my problem.  How
>   > do you describe the effect of applying a filter on top of one or more
>   > other filters?  Andrea wants to use "intersection", but I tend to
>   > think this is too "mathematical" and too vague to explain clearly what
>   > happens.  What would be a good terminology for that?
> 
> How about "filter further"?  "Filter down">  "Filter more strictly"?

I have a fundamental problems with using "filtering" in this context.
Existing Rmail commands that create summaries don't mention filtering
at all.  Here's a typical example:

  rmail-summary-by-topic is an interactive native-compiled Lisp function
  in ‘rmailsum.el’.

  (rmail-summary-by-topic SUBJECT &optional WHOLE-MESSAGE)

  Display a summary of all messages with the given SUBJECT.
  Normally checks just the Subject field of headers; but with prefix
  argument WHOLE-MESSAGE is non-nil, looks in the whole message.
  SUBJECT is a regular expression.

So talking about "filtering" in this context will be "out of the
blue", unless we also change the doc strings of all rmail-summary-by-*
commands and the manual to talk about "filtering".

Moreover, "filtering" is somewhat wrong: the messages themselves
aren't "filtered": they aren't removed from the inbox.  They are just
omitted from the produced summary, and commands that move by summary
lines skip messages that are not in the summary.  So "filtering" here
is not real, it's imaginary, and the documentation will need to
explain that if we want to use that term.

Before we embark on such a massive documentation change, I'd like to
try to find a less invasive change of terminology, if that exists.  Do
you see a way to do that?

Basically, what this feature offers is a way to produce a summary from
messages that are already "summarized" by some criteria.  So I'd
prefer that our terminology alluded to this aspect rather than to
"filtering", because then it would be natural and won't require
significant changes in the documentation of what Rmail summary
commands do.