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: Wed, 24 Oct 2007 15:52:57 -0700 Message-ID: References: <87wstcrw20.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 1193266490 1673 80.91.229.12 (24 Oct 2007 22:54:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2007 22:54:50 +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 Thu Oct 25 00:54:50 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 1Ikp7e-0005ox-2t for ged-emacs-devel@m.gmane.org; Thu, 25 Oct 2007 00:54:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikp7W-0002SK-0p for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2007 18:54:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ikp7R-0002R8-8S for emacs-devel@gnu.org; Wed, 24 Oct 2007 18:54:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ikp7P-0002Pc-Cb for emacs-devel@gnu.org; Wed, 24 Oct 2007 18:54:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ikp7P-0002PQ-9L for emacs-devel@gnu.org; Wed, 24 Oct 2007 18:54:31 -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 1Ikp7I-00071b-UG; Wed, 24 Oct 2007 18:54:25 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9OMsLGS027318; Wed, 24 Oct 2007 16:54:22 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9OLQxbC015582; Wed, 24 Oct 2007 16:54:21 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3318443011193266374; Wed, 24 Oct 2007 15:52:54 -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: <87wstcrw20.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:81669 Archived-At: > > 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. > > Actually this suggests adding a new global mode isearch-buffers-mode. > When it is active and the global variable > isearch-buffers-next-buffer-function > contains a function that return the next buffer from the set of marked > buffers from the buffer list, this could work. But what to do when > isearch enters a ChangeLog buffer that has a buffer-local value > of isearch-buffers-next-buffer-function? After leaving this buffer, > isearch will continue to search the next ChangeLog file, not the next > buffer from the buffer list. I probably don't understand you, but I don't see why another minor mode would be needed or what the problem would be. In my thinking, if buffers are marked in Buffer List, then they are always used. To use another sequence of buffers, such as in a change log mode, either the user or the mode code would need to unmark the Buffer List buffers first. If it is the change-log code that does that, then it could restore the marked buffers when it exits. Alternatively, the mode could just bind isearch-buffers-next-buffer-function for its own use. When it exits, the global binding would take effect. By default, that would mean the marked buffers. Or are you speaking of isearch crossing between buffers that have different values of the function? In that case, the thing to do would be to work from a snapshot: the function value when isearch started. IOW, not let isearch use the current definition of the function, but the definition that was current when it started searching. Again, I'm probably missing your point. Please try again.