RE: isearch multiple buffers

[Drew Adams]

> >> I'll try to find a general solution that will work also for searching
> >> from the buffer list that Drew asked for.
> >
> > Great - thanks. It need not follow what I said or even use the
> > Buffer List. The idea is to have some (interactive) way for a user
> > to select the buffers to be searched.
>
> Selecting the buffers to be searched is not a problem.

It is one problem. If you have implemented that, then it is one less to
address. ;-)

A second problem is letting users somehow order those marked buffers - for
searching and perhaps for other operations. When multiple buffers are
searched, users can sometimes care about the search order.

I mentioned some possibilities for this, but this question could probably
use additional thought and comment. Buffer List already lets you sort by
particular columns, but that's only a crude ordering wrt the marked buffers.

BTW, Buffer List still doesn't let you sort columns in both directions. I do
this in my library buff-menu+.el, but this sorting wasn't accepted for
Emacs. I think it's important to be able to reverse a sort order -
especially if we provide for sorting marked buffers. So if we implement a
way to let users order their marked buffers, we should also provide a key
binding for a command to reverse that order.

> I think the *Buffer List* is a good interface to select them.

I do too.

> The question is
> how to start multi-buffer isearch.  Imagine that you've marked a list
> of buffers in the *Buffer List*.  How to start multi-buffer isearch now?
> Should C-s start multi-buffer isearch in marked files, or should C-s
> still allow searching for the string in the *Buffer List* (this is useful
> for searching buffer names in the *Buffer List*).
>
> This question is not limited to searching buffers from the *Buffer List*.
> To search in multiple files one good user interface would be marking
> a list of files in the dired buffer and starting multi-file isearch in
> marked files - "Incremental Grep"!

Yes - More generally, I think that lots of Dired functionality could
usefully be ported to Buffer List. I mentioned some of this in a previous
post in this thread. In particular, from the moment that commands outside
Buffer List can take advantage of its marked files, the various mark
manipulations available in Dired become good candidates for Buffer List.

Good point about Buffer List searching - another question to deal with. I
don't have a good answer ready; it hadn't occurred to me.

One simple answer would be that to search within the Buffer List buffer you
would just remove all marks first. But if you have many buffers marked, you
might want to remove the marks only temporarily, during searching.

So a simple solution would be to provide a way in Buffer List to toggle the
`>' marks on and off (not the same as toggling marked-vs-unmarked, which
would also be useful). Then, to be able to search within the buffer, you
could temporarily turn off the marks, then turn them all on again with one
keystroke when you're done searching Buffer List. Likewise for Dired. That
might also be useful for other purposes.

Another possibility is to simply say that C-s within the Buffer List does
not do multi-buffer search - it simply searches within the Buffer List. To
search the marked buffers, you would then invoke `C-s' from outside the
Buffer List. That would be simpler and perhaps less confusing. Likewise for
Dired and file searching - `C-s' within Dired would not do multi-file
search; you would need to invoke `C-s' outside Dired for that.

The choice between these two approaches (among others perhaps) might depend
on how often we think users would want to search multiple buffers from
within Buffer List. If seldom, then the second is better; if often, then
perhaps the first is better.

Offhand, I'd say the second is sufficient: invoking `C-s' from within Buffer
List or Dired ignores the marked buffers/files - it doesn't do multi-buffer
search. But I like the idea of being able to toggle a set of marks on and
off. in fact, I'd like that to be available for all kinds of marks (choosing
the type of mark to toggle, perhaps, as we do for `dired-change-marks').