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: Sat, 27 Oct 2007 16:26:33 -0700 Message-ID: References: <87ir4sw4xe.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 1193527652 23380 80.91.229.12 (27 Oct 2007 23:27:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2007 23:27:32 +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 Sun Oct 28 01:27:33 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 1Ilv3y-0001wH-UN for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 01:27:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ilv3p-0006YX-Nj for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2007 19:27:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ilv3m-0006YI-FG for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:27:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ilv3l-0006Y6-3z for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:27:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ilv3k-0006Y3-TH for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:27:16 -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 1Ilv3g-0006j5-KI; Sat, 27 Oct 2007 19:27:12 -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 l9RNR9SO027256; Sat, 27 Oct 2007 17:27:09 -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 l9R799Vd011585; Sat, 27 Oct 2007 17:27:08 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-37.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3324761191193527570; Sat, 27 Oct 2007 16:26:10 -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: <87ir4sw4xe.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:81890 Archived-At: > >> Perhaps the best way to specify a set of buffers to search as a unit > >> is with a fileset. > > > > For those of us unfamiliar with that, could someone please > > summarize what that is and how it would work in this context? > > See (info "(emacs)Filesets"). I see. Thanks. > We definitely could implement isearch through filesets too, but it seems > defining a fileset just to search though some buffers is not the simplest > way to do this. > > Since you suggested to start isearch from the *Buffer List*, you could > compare this method with starting isearch on filesets. >From a cursory look, I'd say that Buffer List should be used. This is about searching buffers, not necessarily file buffers. However, there is a fileset command (`filesets-open') to visit all of the files in a fileset. And if (some or) all are open, then another (new) fileset command, say `filesets-mark-buffers', could mark the corresponding buffers. That way, the interface to isearch would still be Buffer List, but there would be an easy way to search all files in a fileset. Users should not be obliged to define a fileset in order to search multiple buffers, but if they happen to have a fileset defined, then the same mechanism can be used to let them mark and search the buffers of its files. How should command `filesets-mark-buffers' react if only some of a fileset's files are open (visited)? A strict behavior would have it do nothing, requiring you to first open them all. A lax behavior would simply mark all existing buffers that correspond to files in the fileset, whether or not they are all open. I don't know if the lax behavior would be useful or confusing (or both). My guess is that it could be useful: You can open all files in a fileset if you want to, or you can (manually) open only some of them. Even in the latter case, you could then mark all of those that are open, in one fell swoop. One possibility is to let the user choose strict or lax behavior, via an option. BTW, even in the case of searching multiple file buffers, the doc language should speak of it that way, and not in terms of searching "files". Searching a set of files does not imply visiting them. The language of isearch should speak of searching buffers, not files, whether or not filesets are involved.