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#8861: 24.0.50; Isearch: Repeating the last search Date: Tue, 14 Jun 2011 06:11:37 -0700 Message-ID: <19F65DC210FE45AC84732F8E76A374AA@us.oracle.com> References: 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 1308058951 5275 80.91.229.12 (14 Jun 2011 13:42:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2011 13:42:31 +0000 (UTC) To: "'Dani Moncayo'" , <8861@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 14 15:42:27 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 1QWTst-00062i-T8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jun 2011 15:42:24 +0200 Original-Received: from localhost ([::1]:36096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWTss-0003wr-Qu for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jun 2011 09:42:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWTTQ-00067N-TP for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 09:16:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWTTP-0003h6-3F for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 09:16:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWTTO-0003gz-Pl for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 09:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QWTTO-0002zO-18; Tue, 14 Jun 2011 09:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jun 2011 13:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8861 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8861-submit@debbugs.gnu.org id=B8861.130805730211399 (code B ref 8861); Tue, 14 Jun 2011 13:16:01 +0000 Original-Received: (at 8861) by debbugs.gnu.org; 14 Jun 2011 13:15:02 +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 1QWTSP-0002xl-HN for submit@debbugs.gnu.org; Tue, 14 Jun 2011 09:15:01 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QWTSN-0002xK-P3 for 8861@debbugs.gnu.org; Tue, 14 Jun 2011 09:15:00 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5EDBmZ0007043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 13:11:51 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5EDBlrY023036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 13:11:47 GMT Original-Received: from abhmt014.oracle.com (abhmt014.oracle.com [141.146.116.23]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5EDBfdM011714; Tue, 14 Jun 2011 08:11:42 -0500 Original-Received: from dradamslap1 (/10.159.53.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Jun 2011 06:11:41 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcwqkiRUQ0PuURh5TxilJV13ZUsAuwAAInUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4DF75ECC.005E:SCFMA922111,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 14 Jun 2011 09:16:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:47125 Archived-At: Juri or someone else might give a better or different explanation, but here's mine, FWIW. This behavior is not very clear or intuitive, but (a) there is not much that can be done about it, and (b) it can be argued that it is not really a bug. The highlighting could perhaps be turned off completely in this case, since in does not (cannot) correctly indicate only the part of the search string that is incorrect. (But turning it off completely gives the opposite message that there is no search failure.) The highlighting as it appears is at least consistent with the rest of Isearch behavior in this context. The search string was not sought incrementally; that is, no incremental search built it up. So there is no notion of the increment of it that failed. If you hit `DEL' (Backspace) at that point, it is not just the final `e' that is removed, but all of the search string. IOW, you cannot return to a successful search prefix and return in the buffer to a successful search hit position. In this context, the entire search string _is_ the increment: it is sought as a whole. There is no previous successful state to return to, and that principle extends to the success/failure match highlighting. I know and agree that this might not be what a user expects, especially since this highlighting is something new, but it is consistent. The highlighting here, like all the rest of the searching, is not incremental at that point. The search string as a whole is tested and either succeeds (as a whole) or fails (as a whole). The highlighting reflects that. And it can only reflect that. Perhaps we could remove it, but I'm not sure that would be better. In that case the "bug" or unituitive behavior would be that search fails but the search string is not highlighted at all to show failure.