From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text Date: Sun, 6 Nov 2011 10:01:31 -0800 Message-ID: <42725507B3BE47B7A349C08F3F7B7FDC@us.oracle.com> References: <87vcqxuxjo.fsf@mail.jurta.org><87vcqxthgz.fsf@mail.jurta.org><87aa89rzul.fsf@mail.jurta.org><87sjm1nq1b.fsf@mail.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: dough.gmane.org 1320602544 10127 80.91.229.12 (6 Nov 2011 18:02:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Nov 2011 18:02:24 +0000 (UTC) Cc: 9972@debbugs.gnu.org To: "'Dani Moncayo'" , "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 06 19:02:20 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RN72y-0000iG-F3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Nov 2011 19:02:20 +0100 Original-Received: from localhost ([::1]:57602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN72y-0000qv-3H for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Nov 2011 13:02:20 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:58212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN72u-0000qm-RD for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2011 13:02:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RN72t-0004Lj-Ja for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2011 13:02:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN72t-0004LY-Ax for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2011 13:02:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RN75Z-00027I-Iu for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2011 13:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2011 18:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9972 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9972-submit@debbugs.gnu.org id=B9972.13206026738101 (code B ref 9972); Sun, 06 Nov 2011 18:05:01 +0000 Original-Received: (at 9972) by debbugs.gnu.org; 6 Nov 2011 18:04:33 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RN756-00026c-UM for submit@debbugs.gnu.org; Sun, 06 Nov 2011 13:04:33 -0500 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RN755-00026W-JO for 9972@debbugs.gnu.org; Sun, 06 Nov 2011 13:04:32 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA6I1gPb027403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Nov 2011 18:01:43 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pA6I1fiw004421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2011 18:01:42 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pA6I1aVx002012; Sun, 6 Nov 2011 12:01:36 -0600 Original-Received: from dradamslap1 (/10.159.37.242) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Nov 2011 10:01:35 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acycq5f6XrI/ngKUSYqPs842j4As5AAANkjA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A020201.4EB6CB88.0004,ss=1,re=0.594,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 06 Nov 2011 13:05:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53616 Archived-At: > Actually, what I don't like in the current behavior of C-s (and the > other 3) when invoked from the minibuffer is the fact that the current > minibuffer text remains there after hitting C-s (like if I were typed > it, but even being read-only!). Dunno what you mean about the text being read-only. The reason the minibuffer text remains there is that it is the text to be searched. It is not there as the current search string (or search "entry" as you have referred to it). It is there as the text to be searched. Think of the minibuffer as an ordinary buffer with some text in it. The text that is in the minibuffer is text that you typed. Or it is text that you retrieved from a history cycle or search. Or it is text that you retrieved by cycling among the current completion candidates. However the current minibuffer text got there, it is the text that gets searched by C-s/C-r/C-M-s/C-M-r. > That scenario is not like users are used to when the > type `C-s'. Yes it is. The text you see is _not_ the search string. It is the text to be searched. > They expect to see a clean minibuffer > prompt "I-search: ", with the cursor after it. I agree that things can be a bit confusing because the minibuffer is used for both the Isearch prompt and as the buffer to be searched. Perhaps you or Juri has a suggestion how to make this clearer. But your idea of emptying the minibuffer doesn't fly because it is precisely the minibuffer text that is to be searched. > So, what about making the Isearch commands start that way, but > considering the current minibuffer text (the one present before C-s > was invoked) as the first entry for the search, as you pointed out? The minibuffer content (text) is not an Isearch "entry". It is the text to be searched.