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#14729: 24.3.50; Isearch oddity Date: Sat, 29 Jun 2013 20:11:07 -0700 (PDT) Message-ID: References: <87mwqbay6p.fsf@mail.jurta.org> <87haggmv72.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372561935 21013 80.91.229.3 (30 Jun 2013 03:12:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Jun 2013 03:12:15 +0000 (UTC) Cc: 14729@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 Jun 30 05:12:15 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ut83h-0000ro-Ml for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Jun 2013 05:12:13 +0200 Original-Received: from localhost ([::1]:45445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ut83h-0002Nk-6v for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2013 23:12:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ut83Y-0002Fs-Pf for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2013 23:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ut83W-0003AH-KK for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2013 23:12:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ut83W-0003A8-Eu for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2013 23:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ut83W-0007FT-11 for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2013 23:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jun 2013 03:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14729 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14729-submit@debbugs.gnu.org id=B14729.137256187827807 (code B ref 14729); Sun, 30 Jun 2013 03:12:01 +0000 Original-Received: (at 14729) by debbugs.gnu.org; 30 Jun 2013 03:11:18 +0000 Original-Received: from localhost ([127.0.0.1]:48737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ut82n-0007EQ-N4 for submit@debbugs.gnu.org; Sat, 29 Jun 2013 23:11:18 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43741) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ut82l-0007EC-I4 for 14729@debbugs.gnu.org; Sat, 29 Jun 2013 23:11:16 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5U3B9AN009382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Jun 2013 03:11:09 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5U3B8AT029662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jun 2013 03:11:08 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5U3B85t029659; Sun, 30 Jun 2013 03:11:08 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:75733 Archived-At: (There may be another way to approach this. This is what I have to offer.) On way of looking at this has to do with the behavior of `isearch-printing-char'. If you change it to add the following `while' sexp then the reported problem disappears: (defun isearch-printing-char (&optional char count) "Append ordinary printing CHAR to the search string and search. With a numeric prefix arg, append that many copies of CHAR." (interactive (list last-command-event (prefix-numeric-value current-prefix-arg))) ;; ADDED THIS `while'. (while (or (not isearch-success) isearch-error) (isearch-pop-state)) (let ((char (or char last-command-event))) (when (=3D char ?\S-\ ) (setq char ?\ )) (if current-input-method (isearch-process-search-multibyte-characters char count) (isearch-process-search-char char count)))) However, that also changes the behavior in general, in this way: Whenever there is a mismatch and you type something, what you type replaces the mismatched part. That is probably not the behavior we want, in general. It might be the behavior some people want in general or the behavior that anyone might want some of the time. FWIW, in Isearch+ the above `while' is conditional on the value of a user option, `isearchp-drop-mismatch'. Only when the option value is `replace-last' is the `while' evaluated and thus the state popped. There are 3 possible values for the option. Because you might sometimes want different behavior, you can cycle among the values during Isearch using `M-k' (command `isearchp-cycle-mismatch-removal'). The values: nil - Your current input is appended to the search string, even if the string already has a mismatched portion. `replace-last' - Your current input replaces the last mismatched text. You can always see your last input, even if it is a mismatch. And it is available for editing using `M-e' (which puts point at the mismatch position). anything else - Your current input is ignored for searching if it causes a mismatch: it is, in effect, not added to the search string, which thus always has only successful matches. The default value is nil, which gives the same behavior as vanilla Isearch (including the behavior that you reported): When the search does not match and you type more text it is simply appended, even though it does not help with matching (but in the case of a regexp, it might).=20 Value `replace-last' automatically replaces the mismatched portion by what you type. This also has the effect of fixing the scenario you describe. E.g., if you type `bufx' then the `x' is a mismatch for `buffer'. If you then type `m', the `m' replaces the `x' (`bufm'), and the `m' is now the mismatched portion. If you then type `f' then the match is extended to `buff' (there is no longer a mismatch). Any other option value means you never see a mismatch in the search string. Anything you type that does not match is dropped, as if you hadn't typed it. As I say, there might well be another way to give you the behavior you expect/prefer here. The `replace-last' approach is really designed for something other than your scenario. It just happens to take care of this case because what would be a (mistakenly) highlighted `f' is immediately replaced by an unhighlighted `f' (you never see it highlighted). Presumably there is a way to prevent Isearch from recognizing the reported scenario as a mismatch, rather than applying `replace-last' as a bandaid. Perhaps Juri has an idea. He is more familiar with the new Isearch state structure etc.