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 08:20:07 -0700 Message-ID: <8F88488908D147DA819F6B505879A7AF@us.oracle.com> References: <19F65DC210FE45AC84732F8E76A374AA@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1308064897 14595 80.91.229.12 (14 Jun 2011 15:21:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2011 15:21:37 +0000 (UTC) Cc: 8861@debbugs.gnu.org To: "'Dani Moncayo'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 14 17:21:32 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 1QWVQo-0000T1-4q for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jun 2011 17:21:30 +0200 Original-Received: from localhost ([::1]:50867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWVQm-0004xW-Cn for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Jun 2011 11:21:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWVQP-0004x6-Oc for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 11:21:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWVQN-0003MX-JF for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 11:21:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWVQN-0003MQ-9E for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2011 11:21:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QWVQM-0006BC-Ph; Tue, 14 Jun 2011 11:21: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 15:21:02 +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.130806483223711 (code B ref 8861); Tue, 14 Jun 2011 15:21:02 +0000 Original-Received: (at 8861) by debbugs.gnu.org; 14 Jun 2011 15:20:32 +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 1QWVPr-0006AO-RF for submit@debbugs.gnu.org; Tue, 14 Jun 2011 11:20:32 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QWVPp-0006A8-1t for 8861@debbugs.gnu.org; Tue, 14 Jun 2011 11:20:30 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p5EFKJiH003803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 15:20:22 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5EFKJ0o010138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 15:20:19 GMT Original-Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5EFKDP0026231; Tue, 14 Jun 2011 10:20:13 -0500 Original-Received: from dradamslap1 (/10.159.53.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Jun 2011 08:20:11 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcwqncbGEeEq1ERHQiCL9Tu2vUlBvwAAJP1A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4DF77C36.009B: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 11:21: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:47128 Archived-At: > > The highlighting could perhaps be turned off completely in=20 > > this case, since in does not (cannot) correctly indicate > > only the part of the search string that is incorrect. =A0(But > > turning it off completely gives the opposite message that > > there is no search failure.) >=20 > This doesn't make much sense to me. I expect that, whenever Isearch > is active, the search string will always be highlighted to reflect the > matched and unmatched parts at every moment, regardless of how that > string has been introduced (char by char, by copy&paste, by "C-s C-s", > ...) I already acknowledged such expectations from users. I've had the same expectations myself. Dunno what else to say. The fact is that that is not how incremental = search works - so far. Such state - and more than a single state: a history - = is not saved. When you are in the middle of an incremental search, some state is saved = about the last successful position etc. But once you have exited search there = is no way to restore state, other than retrieving the last (or other previous) complete search string to start a new search. We could perhaps save also the last successful prefix of the last search = string, as a means to at least make the highlighting reflect that state. =20 But in any case as soon as you reuse the search string (which is = complete) it is treated as a whole (e.g. hitting `DEL' deletes it all at once). And you = might be reusing a past search string that was completely successful in some = different context (e.g. a different buffer or narrowing). Should we record also = the current buffer and its restriction as part of the search history? This = quickly becomes fairly complex, with design/user intention tradeoffs left and = right, I think.=20 Anyway, I cannot really speak to such implementation matters; I'm no = expert on them. I'm just giving some background explanation. Perhaps Juri L. has = an idea about this he would like to share. But we have discussed the issue = before. > > The highlighting as it appears is at least consistent with=20 > > the rest of Isearch behavior in this context. =A0The search > > string was not sought incrementally; that is, no incremental > > search built it up. =A0So there is no notion of the increment > > of it that failed. =A0If you hit `DEL' (Backspace) at that=20 > > point, it is not just the final `e' that is removed, but all > > of the search string. >=20 > I understand you, but I really disagree. As I've said before, I'd > expect a consistent behavior with independence of the way the search > string has been built. There's really nothing to disagree about here. I'm just explaining what happens. You might like Isearch to remember your entire incremental = search history (interaction), but it does not do so at present, and it never = has. The first question is thus whether what bothers you is just the = highlighting. Are you as bothered about the fact that you cannot resume incrementally = where you left off anyway, i.e., the fact that `DEL' removes not the final = char but the whole search string, and there is thus no saved successful hit to = return to by hitting `DEL', as you are bothered about the highlighting (which = reflects that fact/behavior consistently)? > I don't see the need to have that double treatment. IMHO, it is both > more consistent and useful to have a single behavior. In the example > showed in the OP, if the search string (and the cursor position) was > updated as I suggested, I would have had a more complete/precise > information, since part of my search string did actually have matches > after the point, and that is what I wanted to know. >=20 > In short: I find my proposed behavior both (a) Simpler (more > consistent) and (b) More informative (useful) that the current one. >=20 > (Just my opinion) Patch welcome, I'm sure. And as I say, perhaps Juri has another idea or = a better explanation of the situation. FWIW, one alternative I can imagine, to trying to save enough historical incremental behavior to provide the behavior you expect, would be to = have Isearch do something like the following when you hit C-s C-s and there = is a mismatch: automatically reproduce the behavior of your manually editing = the search string to remove successive rightmost characters and trying to = find a match, then proceeding with the longest successful prefix string. IOW, it would then reproduce what you might do manually in this case, = which would be the following: 1. M-e, to edit the search string 2. DEL, to delete the rightmost char 3. C-s, to look for a match for the search string minus that char 4. If success, done. Else repeat. That is essentially what I do in the Icicles completion highlighting = that this Isearch highlighting was inspired from: try to complete; remove a char; = repeat until success; then highlight the part that didn't match. Actually, = this is optimized using binary search (split the mismatch in half etc.), instead = of proceeding just a char at a time, and the same could be done for = Isearch. That would, in effect, put the previous search string in sync with the = current context (e.g. buffer). I can see that as one possible approach/"solution". But in that case, Isearch would be automatically discarding all that did = not match, so that suffix - and that mismatch information - would in effect = be lost to you. And that info about mismatch could be helpful in some contexts. Imagine = that you search for `foobar' successfully in buffer A, then want to look for = it in buffer `B', where there is `foofizz' but no `foobar'. Maybe in that = case you would like to see that `foobar' does not match, and not just see that = Isearch transforms your C-s C-s string from `foobar' to `foo' for a successful = `foo' search? Sure, you can type `bar' again, or you can yank `foobar' and = then search for it, but that's a bit roundabout. If we took this approach, perhaps we should bind a key to retrieving the discarded mismatch suffix? Or provide a way to easily retrieve it a = char at a time, to in effect reproduce your typing it incrementally (so you need = not know or remember what the mismatch text was). Or perhaps a better approach at that point (after determining the = correct mismatch position for the current context) would be to use the whole = search string, but (a) highlight the correct mismatch portion, and thus (b) let = you, as now, use `M-e C-k' to remove it if you want, and (c) make that the = current Isearch state: reset the failure position. IOW, have Isearch automatically run through all the steps that would be = needed to get to the state of an incremental search that starts with the = successful prefix and proceeds incrementally to the complete (mismatched) search = string, reestablishing the correct mismatch position for the current context. = This is essentially what you are asking for, I think. Dunno how difficult that would be to implement. I'm guessing it's = doable, but Juri or someone else might have more to say about it. The point here is really the question of what it means (what the = behavior should be) to return to a previous search that failed. Or for that matter to = return to a previous search that succeeded but now fails in a different context = (same problem). (And that's why saving a complete previous incremental = history is not really a solution to this problem.) Again, I am not saying that the current behavior is better than the one = you are expecting. I am saying that what you are expecting is not implemented, = and it represents a change in the traditional behavior (wrt DEL etc.). It = might be doable, but it would at least represent an enhancement request. Aside from realizing such an enhancement, the highlighting could I think = easily be turned off completely in this situation. That would not fix the = overall problem/inconsistency, but it would prevent it from being brought to = your attention so prominently.