From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: isearch-yank-char Date: 30 Apr 2004 08:58:45 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87u0z15zze.fsf@floss.red-bean.com> References: Reply-To: kfogel@red-bean.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083356446 5339 80.91.224.253 (30 Apr 2004 20:20:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Apr 2004 20:20:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 30 22:20:41 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BJeUz-00010Z-00 for ; Fri, 30 Apr 2004 22:20:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BJeUx-0003bb-00 for ; Fri, 30 Apr 2004 22:20:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BJeTS-0007dP-3A for emacs-devel@quimby.gnus.org; Fri, 30 Apr 2004 16:19:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BJeTJ-0007aY-QM for emacs-devel@gnu.org; Fri, 30 Apr 2004 16:18:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BJeQr-0006UX-Vy for emacs-devel@gnu.org; Fri, 30 Apr 2004 16:16:57 -0400 Original-Received: from [207.115.63.78] (helo=pimout6-ext.prodigy.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BJeQe-0006RP-Nx for emacs-devel@gnu.org; Fri, 30 Apr 2004 16:16:12 -0400 Original-Received: from floss.red-bean.com (adsl-66-73-175-183.dsl.chcgil.ameritech.net [66.73.175.183]) by pimout6-ext.prodigy.net (8.12.10/8.12.10) with ESMTP id i3UKG5c4198350; Fri, 30 Apr 2004 16:16:09 -0400 Original-Received: from kfogel by floss.red-bean.com with local (Exim 3.34 #1 (Debian)) id 1BJYXN-00073P-00; Fri, 30 Apr 2004 08:58:45 -0500 Original-To: Alan Mackenzie Microsoft: where the service packs are larger than the original releases. In-Reply-To: Original-Lines: 65 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22463 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22463 Alan Mackenzie writes: > Excellent idea! Let's do it! Great! > > 2. Bind C-b in isearch-mode to a function (name TBD) that loses > > one char from the search string. > > NOT SO FAST! Tell me, where does point get left after a C-b? Normally, > one character backwards. No problem. But.... That's what I was thinking. It would be "just as if" you hadn't typed the character just dropped from the search string in the first place. > Where does point get left in a regexp-search after C-b? Suppose that the > last character entered into the regexp search string was a closing > parenthesis (or whatever) that caused the the regexp search to backtrack, > moving point to an earlier position? I can think of several ideas for > handling this, e.g.: Oooh. Glad you asked -- hadn't even thought about isearch-*-regexp, since I rarely use them. > (i) Point moves _forward_ to where it was before the ] was entered, i.e. > C-b works just like in this case; However, the search string might > just have been extended by several characters at once (with M-y). This > looks like getting hairy; > > (ii) C-b only works in normal (non-regexp) search; > > (iii) C-b is disallowed in regexp-search for quirky characters like ); > > (iv) C-b is disallowed in regexp-search whenever it would cause point to > jump forward; > > (v) Point is left where it was, and the currently highlighted "match" is > no longer a match at all; > > (vi) C-b in such circumstances acts like M-e, leaving the user directly > editing the search string. > > I think it would be a good idea to resolve this issue before implementing > a C-b. I'm not sure whether I'd rather do without C-b here than have > some ugly inconsistency, even if that inconsistency only appears in > marginal circumstances. Yes, we should figure out the desired behavior first. I think it should drop the last (regexp-quoted) character inserted into the search string, for consistency, and then the search string would behave as it normally would if that character (or characters, if it got regexp-quoted) were dropped. In other words, your option (i), which is to behave almost like , except remember that actually drops "last unit added". I.e., del after C-w drops a word, and after C-y can drop even more. But C-b would always drop a character, plus any regexp quoting that got added to that character when it was brought into the search string. I think to flesh this proposal out, we'd have to look more into how behaves currently in the isearch-*-regexp functions. I haven't had time to do that yet, so please don't take the above as much more than hand-waving :-). -Karl