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:19:59 -0700 Message-ID: References: <47227FDE.1040506@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1193444490 11931 80.91.229.12 (27 Oct 2007 00:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2007 00:21:30 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Lennart Borgman \(gmail\)" , "Juri Linkov" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 27 02:21:30 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 1IlZQg-0002f8-FH for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2007 02:21:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlZQX-0001L3-LD for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2007 20:21:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IlZQT-0001J2-Tz for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:21:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IlZQR-0001Ii-T2 for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:21:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlZQR-0001Ic-Ki for emacs-devel@gnu.org; Fri, 26 Oct 2007 20:21:15 -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 1IlZQO-0004Hr-BC; Fri, 26 Oct 2007 20:21: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 l9R0L8bj032683; Fri, 26 Oct 2007 18:21:08 -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 l9QLmDFZ029029; Fri, 26 Oct 2007 18:21:07 -0600 Original-Received: from 141.144.88.161 by acsmt351.oracle.com with ESMTP id 3324471551193444391; Fri, 26 Oct 2007 17:19:51 -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: <47227FDE.1040506@gmail.com> 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:81810 Archived-At: > > Selecting the buffers to be searched is not a problem. I think the > > *Buffer List* is a good interface to select them. 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*). > > I believe most users would be surprised if C-s started multi-buffer > isearch for the marked files. Until they learn about it. It's not exactly dangerous, but it could be surprising the first time, if you haven't heard about it first. > But it is still a good "mnemonic". Maybe > ask the user if he/she wants to search the marked files? I'm against that. Asking the user for confirmation should be a last resort, reserved for something that makes changes or has drastic consequences. It should not be used just because we introduce a new feature that might surprise a user who is not yet aware of it. If we did that each time, we would by now have confirmation questions all over the place.