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: Tue, 23 Oct 2007 17:32:42 -0700 Message-ID: References: <873aw1fnex.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 1193186103 2726 80.91.229.12 (24 Oct 2007 00:35:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2007 00:35:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Juri Linkov" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 02:35:04 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 1IkUD8-0003K2-K5 for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 02:35:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkUD0-0006Si-G8 for ged-emacs-devel@m.gmane.org; Tue, 23 Oct 2007 20:34:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IkUCw-0006Rs-4p for emacs-devel@gnu.org; Tue, 23 Oct 2007 20:34:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IkUCu-0006Rd-Mo for emacs-devel@gnu.org; Tue, 23 Oct 2007 20:34:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IkUCu-0006RY-G5 for emacs-devel@gnu.org; Tue, 23 Oct 2007 20:34:48 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IkUCr-00010R-IF; Tue, 23 Oct 2007 20:34:45 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9O0YZbp016765; Tue, 23 Oct 2007 18:34:35 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9NC1srQ017298; Tue, 23 Oct 2007 18:34:34 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-176.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3314659971193185961; Tue, 23 Oct 2007 17:32:41 -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: <873aw1fnex.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:81601 Archived-At: > I think users should be aware of the active multi-buffer search, so moving > to another buffer will not be a surprise. There are two places where this > indication can be added: in the mode line as a minor mode "lighter" string, > or/and as the prefix/suffix of the isearch message, e.g.: > > I-search: search_string [Repeat for next buffer] > Multi-I-search: search_string [Repeat for next buffer] > X-I-search: search_string [Repeat for next buffer] > X-search: search_string [Repeat for next buffer] Sorry if this is irrelevant (I haven't been following this thread) - Looking briefly at the first message in the thread, I see `isearch-buffers-next-buffer-function', which a user (or library) could presumably define. And I see that that variable is set to `change-log-isearch-next-buffer' for use with change logs - OK. I don't see any other code that deals with defining the set of buffers to be searched. (Again, I haven't followed closely, so I might have missed it.) Is there no way for a user to interactively choose the buffers to search? If so, how about at least letting a user search, say, all of the buffers marked (with `>') in the Buffer List (C-x C-b), in the order they currently appear in that list? That is, have the default value of `isearch-buffers-next-buffer-function' be a function that provides this behavior. I think that if users could easily choose the buffers and the order (using Buffer List and perhaps in other ways too), this would be more useful, and users would be less surprised by the behavior. Buffer List already offers one way to select buffers and order them. And if this were available, it might also serve as an incentive to have one or more buffer-menu commands that mark buffers according to a regexp - similar to what `dired-mark-files-regexp' does.