From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: isearch multiple buffers Date: Fri, 26 Oct 2007 17:13:33 -0700 Message-ID: References: <87ir4tqwj4.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1193444035 10857 80.91.229.12 (27 Oct 2007 00:13:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2007 00:13:55 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Juri Linkov" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 27 02:13:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IlZJL-0001CB-9P for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2007 02:13:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlZJC-0007jr-Ge for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2007 20:13:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IlZJ4-0007fp-01 for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:13:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IlZJ3-0007fK-7k for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:13:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlZJ3-0007fG-5R for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:13:37 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IlZIx-00030Q-QF; Fri, 26 Oct 2007 20:13:32 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9R0DTlf029801; Fri, 26 Oct 2007 19:13:29 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9QDxS9T027228; Fri, 26 Oct 2007 18:13:28 -0600 Original-Received: from 141.144.88.161 by acsmt351.oracle.com with ESMTP id 3322556111193444004; Fri, 26 Oct 2007 17:13:24 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87ir4tqwj4.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:81809 Archived-At: > >> 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').