From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: Incremental search don't append wrongly typed characters Date: Wed, 12 Dec 2012 18:53:30 -0800 Message-ID: <6CC3ADEF192C4507A44DC3EEDF9DBAFC@us.oracle.com> References: <2EABD5DB8D2642EA824C1AA2972F25BF@us.oracle.com><0F0BA88297E349FAA1EB80B663790472@us.oracle.com> <7A0E8A0D76E94C5BBC95EF828DEA4D47@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1355367223 9882 80.91.229.3 (13 Dec 2012 02:53:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Dec 2012 02:53:43 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: "'Dmitry Gusev'" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 13 03:53:57 2012 Return-path: Envelope-to: geh-help-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 1Tiyvt-0003kY-Ka for geh-help-gnu-emacs@m.gmane.org; Thu, 13 Dec 2012 03:53:57 +0100 Original-Received: from localhost ([::1]:35868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiyvg-0003lv-Tn for geh-help-gnu-emacs@m.gmane.org; Wed, 12 Dec 2012 21:53:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiyva-0003lq-Rs for help-gnu-emacs@gnu.org; Wed, 12 Dec 2012 21:53:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiyvZ-0008V9-HM for help-gnu-emacs@gnu.org; Wed, 12 Dec 2012 21:53:38 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiyvZ-0008V0-9p for help-gnu-emacs@gnu.org; Wed, 12 Dec 2012 21:53:37 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBD2rYOU008410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Dec 2012 02:53:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBD2rXC4007600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 02:53:34 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qBD2rXha010557; Wed, 12 Dec 2012 20:53:33 -0600 Original-Received: from dradamslap1 (/10.159.164.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Dec 2012 18:53:33 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7A0E8A0D76E94C5BBC95EF828DEA4D47@us.oracle.com> Thread-Index: Ac3Yu9qBGKP9cnz/Q4qJsAHCl1fOeAAAI6IwAAHDdyAABi60EA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:88157 Archived-At: >>> Drew, thanks for the answer. Unfortunately I need a different >>> behavior in my particular case. I was proposed with similar >>> work-around also on stack overflow. Though, I'm often using >>> incremental search for query specific tags in a large text file >>> which is used like database system with help of some configuration >>> and scripts. Before each incremental search there is a macro >>> which places me to BOF and afterwards starts incremental search. >>> For this scheme it would be very convenient just not to append >>> mismatched part at all. I understand that it's not that standard >>> feature and I use different approach when let's say coding or >>> typing text but again for this particular case I need the >>> mentioned behavior. It will save me some additional clicks to >>> backspace and/or c-s c-g. In other words: I'm looking for a >>> way of not showing mismatched characters during incremental search. >>> Thanks a lot for your time. >> >> But I think that what I described: a key that deletes the >> mismatched portion, might actually solve your problem of >> searching within a keyboard macro. When defining the macro, >> you could presumably just hit that key when typing the search >> string is "done". If there is no mismatched portion for a >> given search, then the key would do nothing. >> >> However, the interactive part of using your macro wrt >> searching is not really clear to me. So maybe I'm missing something. >> >> Anyway, such a key does not exist yet, but if I get some time >> I'll try to come up with it. Or perhaps someone else (you?) >> will beat me to it. Look in isearch.el for the part of the >> code that identifies the mismatched portion for highlighting, >> or the part of `isearch-edit-string' that moves the cursor to the >> mismatch beginning. HTH. > > Of course, `C-g' removes the mismatch portion. But if there > is no mismatch portion then it cancels searching, instead of > being a no-op. This command removes the mismatch part and is a no-op if there is no mismatch. (defun foo () "..." (interactive) (while (or (not isearch-success) (if (boundp 'isearch-error) isearch-error isearch-invalid-regexp)) (isearch-pop-state)) (isearch-update)) (define-key isearch-mode-map "\C-o" 'foo)