bug#4725: 23.1; doc of misearch-* commands (commands?)

["Drew Adams" <drew.adams@oracle.com>]

> > If the list variable is already populated, then use that 
> > value. This lets users populate the variable ahead of time
> > and then still use these commands interactively.
> >
> > If the list variable is null, then just have a simple loop 
> > for users to enter a buffer/file name (e.g. with completion),
> > and end with an empty string. IOW, foo RET bar RET RET to
> > give ("foo" "bar").
> 
> `multi-isearch' was designed to be similar to `multi-occur'.
> Currently we have a set of commands:
> 
>   isearch-forward
>   isearch-forward-regexp
>   occur
>   multi-occur
>   multi-occur-in-matching-buffers
> 
> What is missing now and candidates to be implemented are
> 8 analogous commands:
> 
>   multi-isearch-buffers
>   multi-isearch-buffers-regexp
>   multi-isearch-buffers-matching
>   multi-isearch-buffers-regexp-matching
>   multi-isearch-files
>   multi-isearch-files-regexp
>   multi-isearch-files-matching
>   multi-isearch-files-regexp-matching

Hi Juri,

It's your call, I guess, but that sounds like a lot, for what it's worth.

I'd suggest having just simple commands that let you enter buffer/file names, as
I said above.

If the list variable is already populated, then that would be used, without the
user inputting any names. That also lets users populate the variable in other
ways (e.g. by regexp matching). You might want one separate command that lets
you populate the variable by entering a regexp to match (against buffer or file
names).

Anyway, do whatever you want in this regard. I agree that it's good for users to
be able to both (a) choose files/buffers by name individually, and (b) choose
them by regexp matching.

There are of course many possibilities for defining a set of such names. One
that exists already for files is filesets. That too could be leveraged as one
way to specify the file names you want.

It's a bit of a shame to have zillions of commands, each of which differs by (a)
the type of object chosen, (b) whether matching is literal or regexp, and
possibly (c) whether the objects are chosen explicitly or by pattern matching.

We could also try combining a few at a time in the same command, using a prefix
arg to distinguish (e.g. file vs buffer or regexp vs literal or both). That's
probably a question of preference - I'd usually sooner have a single command to
do this kind of thing, and then consult the doc string if I forget the different
prefix-arg possibilities. I get lost in a sea of similar seeming command names.

Again, though, please do whatever you like here - it's OK by me.

HTH - Drew