From drew.adams@oracle.com Wed Oct 14 13:50:10 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Oct 2009 20:50:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EKo9SQ032719 for ; Wed, 14 Oct 2009 13:50:10 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MyAnQ-0003EH-Un for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 16:50:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MyAnM-0003Dk-Cr for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 16:50:08 -0400 Received: from [199.232.76.173] (port=41529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MyAnM-0003Dh-83 for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 16:50:04 -0400 Received: from rcsinet12.oracle.com ([148.87.113.124]:17320 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MyAnK-0008Br-31 for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 16:50:03 -0400 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EKnbgw019791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Oct 2009 20:49:38 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EG5pQb016632 for ; Wed, 14 Oct 2009 20:49:58 GMT Received: from abhmt012.oracle.com by acsmt358.oracle.com with ESMTP id 20409917021255553386; Wed, 14 Oct 2009 15:49:46 -0500 Received: from dradamslap1 (/141.144.160.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Oct 2009 13:49:46 -0700 From: "Drew Adams" To: Subject: 23.1; doc of misearch-* commands (commands?) Date: Wed, 14 Oct 2009 13:49:52 -0700 Message-ID: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpND+DuBHS9nYUNRI2+oHs0IMISKw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4AD63975.0120:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q In NEWS it says: ** The package misearch.el has been added. It allows Isearch to search through multiple buffers. A variable `multi-isearch-next-buffer-function' defines the function to call to get the next buffer to search in the series of multiple buffers. Top-level commands `multi-isearch-buffers', `multi-isearch-buffers-regexp', `multi-isearch-files' and `multi-isearch-files-regexp' accept a single argument that specifies a list of buffers/files to search for a string/regexp. But this is false. The functions `multi-isearch-buffers', `multi-isearch-buffers-regexp', `multi-isearch-files' and `multi-isearch-files-regexp', defined in misearch.el, are not defined as commands. 1. Shouldn't they be commands? I.e., this is the first bug. Or else change the NEWS item. 2. I find no explanation of using Isearch with multiple buffers or files anywhere, including in the Emacs manual. This needs to be documented somewhere. Logically, this should be explained in a new section of the Isearch chapter of the Emacs manual. It is even the case that multi-isearch is handled, in its essentials, in isearch.el (not in misearch.el). So this is really an integral part of Isearch. It needs to be properly documented as such. That means at least (1) in the Emacs manual and (2) in the file Commentary of isearch.el. I would even say that it should be documented how to use the multi-isearch framework to set up multiple buffers etc. for searching. It's not obvious (1) that you can do that or (2) how to do that. There is no reason not to let Emacs-Lisp programmers know about this. This is provided out of the box as part of Isearch, and it should be well documented. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From juri@jurta.org Wed Oct 14 14:58:47 2009 Received: (at 4725) by emacsbugs.donarmstrong.com; 14 Oct 2009 21:58:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9ELwjmM010934 for <4725@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 14:58:47 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.99.144.cable.starman.ee [82.131.99.144]) by mx1.starman.ee (Postfix) with ESMTP id 9BA8F3F41AE; Thu, 15 Oct 2009 00:58:39 +0300 (EEST) From: Juri Linkov To: Drew Adams Cc: 4725@debbugs.gnu.org Subject: Re: bug#4725: 23.1; doc of misearch-* commands (commands?) Organization: JURTA References: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> Date: Thu, 15 Oct 2009 00:57:17 +0300 In-Reply-To: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> (Drew Adams's message of "Wed, 14 Oct 2009 13:49:52 -0700") Message-ID: <878wfdvdtu.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > In NEWS it says: > > ** The package misearch.el has been added. It allows Isearch to search > through multiple buffers. A variable `multi-isearch-next-buffer-function' > defines the function to call to get the next buffer to search in the series > of multiple buffers. Top-level commands `multi-isearch-buffers', > `multi-isearch-buffers-regexp', `multi-isearch-files' and > `multi-isearch-files-regexp' accept a single argument that specifies > a list of buffers/files to search for a string/regexp. > > But this is false. The functions `multi-isearch-buffers', > `multi-isearch-buffers-regexp', `multi-isearch-files' and > `multi-isearch-files-regexp', defined in misearch.el, are not defined > as commands. > > 1. Shouldn't they be commands? I.e., this is the first bug. Yes, they should be commands. These command should allow the user to select interactively a list of buffers or files to search. Currently I have no idea about the best UI for this. Suggestions welcome. > 2. I find no explanation of using Isearch with multiple buffers or > files anywhere, including in the Emacs manual. This needs to be > documented somewhere. > > Logically, this should be explained in a new section of the Isearch > chapter of the Emacs manual. It is even the case that multi-isearch is > handled, in its essentials, in isearch.el (not in misearch.el). So > this is really an integral part of Isearch. It needs to be properly > documented as such. That means at least (1) in the Emacs manual and > (2) in the file Commentary of isearch.el. (3) the Emacs Lisp Reference Manual (4) in the file Commentary of misearch.el I prefer (4) since it is not a core feature to be documented in the Info manual. -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Wed Oct 14 15:18:00 2009 Received: (at 4725) by emacsbugs.donarmstrong.com; 14 Oct 2009 22:18:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EMHx9w014671 for <4725@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 15:18:00 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EMHSUe009440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 22:17:29 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EKmDp1020656; Wed, 14 Oct 2009 22:18:49 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 20410526401255558666; Wed, 14 Oct 2009 15:17:46 -0700 Received: from dradamslap1 (/141.144.160.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Oct 2009 15:17:46 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4725@debbugs.gnu.org> References: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> <878wfdvdtu.fsf@mail.jurta.org> Subject: RE: bug#4725: 23.1; doc of misearch-* commands (commands?) Date: Wed, 14 Oct 2009 15:17:52 -0700 Message-ID: <200BE6E2E4C04E0CB402FC249FD0F66E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <878wfdvdtu.fsf@mail.jurta.org> Thread-Index: AcpNGYaHxiNgMoFIQ3GfJqDxdVrSeAAASjvg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4AD64E0C.00E6:SCFMA4539814,ss=1,fgs=0 > > 1. Shouldn't they be commands? I.e., this is the first bug. > > Yes, they should be commands. These command should allow the user > to select interactively a list of buffers or files to search. > Currently I have no idea about the best UI for this. > Suggestions welcome. I guess your question is about how to interactively populate the buffer/file list? If so, I'd say keep it simple: If the list variable is already populated, then use that value. This lets users populate the variable ahead of time and then still use these commands interactively. If the list variable is null, then just have a simple loop for users to enter a buffer/file name (e.g. with completion), and end with an empty string. IOW, foo RET bar RET RET to give ("foo" "bar"). Obviously, users can also wrap these functions with a `let' that binds the list variable and define a new command that is appropriate to some particular list that is constructed in some particular way. The point here is just to have a couple rudimentary commands as a basis - IOW, to just turn these functions into commands in a simple way. > > 2. I find no explanation of using Isearch with multiple buffers or > > files anywhere, including in the Emacs manual. This needs to be > > documented somewhere. > > > > Logically, this should be explained in a new section of the Isearch > > chapter of the Emacs manual. It is even the case that > > multi-isearch is > > handled, in its essentials, in isearch.el (not in misearch.el). So > > this is really an integral part of Isearch. It needs to be properly > > documented as such. That means at least (1) in the Emacs manual and > > (2) in the file Commentary of isearch.el. > > (3) the Emacs Lisp Reference Manual > (4) in the file Commentary of misearch.el > > I prefer (4) since it is not a core feature to be documented > in the Info manual. I meant _at least_ #1 AND #2. I think this is an important part of Isearch - at least as important as word search, for instance. There's no reason not to document it in the Emacs manual - the description would be short. The implementation is factored into misearch.el and isearch.el, but the feature should be mentioned (also) in the Commentary of isearch.el, just as other search features are mentioned. That Commentary is the overall description of Isearch, from an implementation point of view. It's OK to also say "see misearch.el for details about multi-search" etc. From juri@jurta.org Thu Oct 15 15:31:43 2009 Received: (at 4725) by emacsbugs.donarmstrong.com; 15 Oct 2009 22:31:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9FMVgoB031945 for <4725@emacsbugs.donarmstrong.com>; Thu, 15 Oct 2009 15:31:43 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.55.26.cable.starman.ee [82.131.55.26]) by mx2.starman.ee (Postfix) with ESMTP id 0AB9A3F4105; Fri, 16 Oct 2009 01:31:29 +0300 (EEST) From: Juri Linkov To: "Drew Adams" Cc: <4725@debbugs.gnu.org> Subject: Re: bug#4725: 23.1; doc of misearch-* commands (commands?) Organization: JURTA References: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> <878wfdvdtu.fsf@mail.jurta.org> <200BE6E2E4C04E0CB402FC249FD0F66E@us.oracle.com> Date: Fri, 16 Oct 2009 01:27:19 +0300 In-Reply-To: <200BE6E2E4C04E0CB402FC249FD0F66E@us.oracle.com> (Drew Adams's message of "Wed, 14 Oct 2009 15:17:52 -0700") Message-ID: <87my3s2vko.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > If the list variable is already populated, then use that value. This lets users > populate the variable ahead of time and then still use these commands > interactively. > > If the list variable is null, then just have a simple loop for users to enter a > buffer/file name (e.g. with completion), and end with an empty string. IOW, foo > RET bar RET RET to give ("foo" "bar"). `multi-isearch' was designed to be similar to `multi-occur'. Currently we have a set of commands: isearch-forward search for a string in the current buffer isearch-forward-regexp search for a regexp in the current buffer occur search for a regexp in the current buffer multi-occur search for a regexp through multiple buffers where the user specifies the buffer names one by one multi-occur-in-matching-buffers search for a regexp through multiple buffers where the user specifies the buffers to search by a regexp What is missing now and candidates to be implemented are 8 analogous commands: multi-isearch-buffers search for a string through multiple buffers where the user specifies the buffer names one by one multi-isearch-buffers-regexp search for a regexp through multiple buffers where the user specifies the buffer names one by one multi-isearch-buffers-matching search for a string through multiple buffers where the user specifies the buffers to search by a regexp multi-isearch-buffers-regexp-matching search for a regexp through multiple buffers where the user specifies the buffers to search by a regexp multi-isearch-files search for a string through multiple files where the user specifies the file names one by one multi-isearch-files-regexp search for a regexp through multiple files where the user specifies the file names one by one multi-isearch-files-matching search for a string through multiple files where the user specifies the files to search by a regexp multi-isearch-files-regexp-matching search for a regexp through multiple files where the user specifies the files to search by a regexp -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Thu Oct 15 15:50:33 2009 Received: (at 4725) by emacsbugs.donarmstrong.com; 15 Oct 2009 22:50:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9FMoWck002651 for <4725@emacsbugs.donarmstrong.com>; Thu, 15 Oct 2009 15:50:33 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9FMoj0R018610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Oct 2009 22:50:46 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9FCbLt0031303; Thu, 15 Oct 2009 22:50:24 GMT Received: from abhmt009.oracle.com by acsmt357.oracle.com with ESMTP id 20436938221255646957; Thu, 15 Oct 2009 17:49:17 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Oct 2009 15:49:17 -0700 From: "Drew Adams" To: "'Juri Linkov'" Cc: <4725@debbugs.gnu.org> References: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com><878wfdvdtu.fsf@mail.jurta.org><200BE6E2E4C04E0CB402FC249FD0F66E@us.oracle.com> <87my3s2vko.fsf@mail.jurta.org> Subject: RE: bug#4725: 23.1; doc of misearch-* commands (commands?) Date: Thu, 15 Oct 2009 15:49:21 -0700 Message-ID: <3D28EDE8022C470E8A8A37C632BF89C9@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87my3s2vko.fsf@mail.jurta.org> Thread-Index: AcpN50mJbIVzZrdeRg2KWM4B6Qn/aQAAHmvw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4AD7A72F.00AC:SCFMA4539814,ss=1,fgs=0 > > If the list variable is already populated, then use that > > value. This lets users populate the variable ahead of time > > and then still use these commands interactively. > > > > If the list variable is null, then just have a simple loop > > for users to enter a buffer/file name (e.g. with completion), > > and end with an empty string. IOW, foo RET bar RET RET to > > give ("foo" "bar"). > > `multi-isearch' was designed to be similar to `multi-occur'. > Currently we have a set of commands: > > isearch-forward > isearch-forward-regexp > occur > multi-occur > multi-occur-in-matching-buffers > > What is missing now and candidates to be implemented are > 8 analogous commands: > > multi-isearch-buffers > multi-isearch-buffers-regexp > multi-isearch-buffers-matching > multi-isearch-buffers-regexp-matching > multi-isearch-files > multi-isearch-files-regexp > multi-isearch-files-matching > multi-isearch-files-regexp-matching Hi Juri, It's your call, I guess, but that sounds like a lot, for what it's worth. I'd suggest having just simple commands that let you enter buffer/file names, as I said above. If the list variable is already populated, then that would be used, without the user inputting any names. That also lets users populate the variable in other ways (e.g. by regexp matching). You might want one separate command that lets you populate the variable by entering a regexp to match (against buffer or file names). Anyway, do whatever you want in this regard. I agree that it's good for users to be able to both (a) choose files/buffers by name individually, and (b) choose them by regexp matching. There are of course many possibilities for defining a set of such names. One that exists already for files is filesets. That too could be leveraged as one way to specify the file names you want. It's a bit of a shame to have zillions of commands, each of which differs by (a) the type of object chosen, (b) whether matching is literal or regexp, and possibly (c) whether the objects are chosen explicitly or by pattern matching. We could also try combining a few at a time in the same command, using a prefix arg to distinguish (e.g. file vs buffer or regexp vs literal or both). That's probably a question of preference - I'd usually sooner have a single command to do this kind of thing, and then consult the doc string if I forget the different prefix-arg possibilities. I get lost in a sea of similar seeming command names. Again, though, please do whatever you like here - it's OK by me. HTH - Drew From juri@jurta.org Mon Nov 30 11:45:03 2009 Received: (at 4725-done) by emacsbugs.donarmstrong.com; 30 Nov 2009 19:45:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out4.starman.ee [85.253.0.6]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nAUJj2lh018085 for <4725-done@emacsbugs.donarmstrong.com>; Mon, 30 Nov 2009 11:45:03 -0800 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.52.137.cable.starman.ee [82.131.52.137]) by mx2.starman.ee (Postfix) with ESMTP id AE03A3F411E; Mon, 30 Nov 2009 21:44:55 +0200 (EET) From: Juri Linkov To: "Drew Adams" Cc: 4725-done@debbugs.gnu.org Subject: Re: bug#4725: 23.1; doc of misearch-* commands (commands?) Organization: JURTA References: <18FECACAE8904F2A9A26016A02CCA5F0@us.oracle.com> <878wfdvdtu.fsf@mail.jurta.org> <200BE6E2E4C04E0CB402FC249FD0F66E@us.oracle.com> <87my3s2vko.fsf@mail.jurta.org> <3D28EDE8022C470E8A8A37C632BF89C9@us.oracle.com> Date: Mon, 30 Nov 2009 21:44:18 +0200 In-Reply-To: <3D28EDE8022C470E8A8A37C632BF89C9@us.oracle.com> (Drew Adams's message of "Thu, 15 Oct 2009 15:49:21 -0700") Message-ID: <87r5rflrvx.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> What is missing now and candidates to be implemented are >> 8 analogous commands: >> >> multi-isearch-buffers >> multi-isearch-buffers-regexp >> multi-isearch-buffers-matching >> multi-isearch-buffers-regexp-matching >> multi-isearch-files >> multi-isearch-files-regexp >> multi-isearch-files-matching >> multi-isearch-files-regexp-matching > > I'd suggest having just simple commands that let you enter buffer/file names, as > I said above. > > Anyway, do whatever you want in this regard. I agree that it's good for users to > be able to both (a) choose files/buffers by name individually, and (b) choose > them by regexp matching. I agree 8 commands is too much. So I left the number of commands unchanged. Now interactively `multi-isearch-buffers' and `multi-isearch-buffers-regexp' read buffer names to search, one by one, ended with RET. With a prefix argument, they ask for a regexp, and search in buffers whose names match the specified regexp. Interactively `multi-isearch-files' and `multi-isearch-files-regexp' read file names to search, one by one, ended with RET. With a prefix argument, they ask for a wildcard, and search in file buffers whose file names match the specified wildcard. (PS: Some new reading functions duplicate some code from other existing functions with subtle differences, and I see no way to use existing functions as is, so I added comments that point to original code). -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Aug 18 14:20:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 29 Dec 2009 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator