From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [PATCH] (Or "question"...) isearch-kill-found Date: Mon, 31 May 2010 12:14:01 -0700 Message-ID: References: <87vda59rby.fsf@mail.jurta.org> <87vda45euq.fsf@stupidchicken.com> 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 1275333362 26355 80.91.229.12 (31 May 2010 19:16:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 19:16:02 +0000 (UTC) Cc: 'Juri Linkov' , 'Emacs-Devel devel' , 'Deniz Dogan' To: "'Stefan Monnier'" , "'Chong Yidong'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 21:16:00 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OJASq-0000O2-Do for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 21:15:56 +0200 Original-Received: from localhost ([127.0.0.1]:36036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJASp-0003LK-K3 for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 15:15:55 -0400 Original-Received: from [140.186.70.92] (port=32853 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJASh-0003KD-Pe for emacs-devel@gnu.org; Mon, 31 May 2010 15:15:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJASg-0000S2-6S for emacs-devel@gnu.org; Mon, 31 May 2010 15:15:47 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:20926) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJASg-0000Rb-0Q for emacs-devel@gnu.org; Mon, 31 May 2010 15:15:46 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VJFfac020263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 May 2010 19:15:43 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4VHJ5c6023894; Mon, 31 May 2010 19:15:40 GMT Original-Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 311365791275333253; Mon, 31 May 2010 12:14:13 -0700 Original-Received: from dradamslap1 (/10.175.236.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 May 2010 12:14:13 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcsA3dt3k9LbR15bR6eiLxIrvG7PugACfeCg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4C040ADF.0116:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125406 Archived-At: > Every new key we use tends to collide with its current use of "exit > isearch and run the command globally bound to that key". I.e. people > who currently expect C-d/delete to exit isearch and delete > the next char will be badly surprised. > > Now, I haven't heard a proposal yet that doesn't suffer from this kind > of problem... > > I'm not sure C-SPC is a good choice (OT1H it's pretty common to use > C-SPC to exit isearch, so many uses will be affected, What you're thinking of: `C-s KEY C-w', where KEY exits isearch and sets the mark at the search-match start. You use `C-w' only if you want to delete the selected text. In `delete-selection-mode', you could use `C-s KEY abcd' to replace the text with `abcd'. Or you could extend the active region (`M-f' etc.). If you do the search+kill several times in succession: `C-s KEY C-w C-s C-s KEY C-w...'. Likewise, for replacements. What you say about the limitation regarding the choice of KEY is correct. But a single-touch chord or key such as `C-SPC' is not a big deal - you just hit it twice to get the normal effect (almost - there will be an extra mark on the ring). Or hit `RET' and then the key: `RET C-SPC'. The alternative that I proposed does not affect any keys that exit isearch - you exit it normally, any way you want. What it does do is leave the mark-setting on or off until you toggle it, with `C-SPC' during isearch. IOW, once you've hit `C-SPC' to turn marking on: `C-s RET C-w' or `C-s RET abcd', where RET could be any other key that exits isearch. If you do the search+kill several times in succession: `C-s RET C-w C-s C-s RET C-w...'. This is identical to your case above, with RET (or any exiting key) in place of KEY. So that's the choice I see: 1. a KEY (e.g. C-SPC) to exit and mark versus 2. a KEY (e.g. C-SPC) to toggle marking #1 has the disadvantage that KEY can no longer be used to exit normally. But that just means you have to hit KEY twice to get the normal behavior. (Well, ALMOST the normal behavior, because the first hit adds a position to the mark ring.) #2 has the disadvantage that you need to turn it off if you want to do this only as a one-off action. But that just means you need to hit KEY a second time. The choice I think depends on how often you (a) want to exit normally using KEY versus (b) how often you want to do this only as a one-off. For #1, each time you would exit normally using KEY you need to hit KEY twice. For #2, each time you would set mark as a one-off you need to hit KEY twice. For #2, if you never use this marking feature, then nothing changes for you. For #1, if you never use KEY to exit normally, then nothing changes for you. If you use this feature sometimes, but rarely, then change "never" and "nothing" to "rarely" and "almost nothing". For people who use this rarely or never, #2 is preferable.