From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: killing the result of isearch Date: Wed, 8 Nov 2017 11:50:31 -0700 Message-ID: <20171108113651593115124@bob.proulx.com> References: <433bd3d0-a506-4d89-9d10-dcbfb0e23be0@default> <852BAA28-2A50-4AD9-B8D6-9F06905A4395@gmail.com> <20171107132316472375613@bob.proulx.com> <20171107200447776721692@bob.proulx.com> <891975A1-3267-4B19-9DB8-B69A1D1CA124@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1510167072 18169 195.159.176.226 (8 Nov 2017 18:51:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 18:51:12 +0000 (UTC) User-Agent: NeoMutt/20170609 (1.8.3) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Nov 08 19:51:02 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCVRD-0004CV-3U for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 19:50:59 +0100 Original-Received: from localhost ([::1]:33488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCVRK-0004aB-FJ for geh-help-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 13:51:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCVQq-0004a4-Lt for help-gnu-emacs@gnu.org; Wed, 08 Nov 2017 13:50:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCVQn-0003xZ-JJ for help-gnu-emacs@gnu.org; Wed, 08 Nov 2017 13:50:36 -0500 Original-Received: from havoc.proulx.com ([96.88.95.61]:49901) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCVQn-0003xM-D1 for help-gnu-emacs@gnu.org; Wed, 08 Nov 2017 13:50:33 -0500 Original-Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id 037AB457 for ; Wed, 8 Nov 2017 11:50:32 -0700 (MST) Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id BA9A7217E3 for ; Wed, 8 Nov 2017 11:50:31 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 97B842DC5E; Wed, 8 Nov 2017 11:50:31 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <891975A1-3267-4B19-9DB8-B69A1D1CA124@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.help:114814 Archived-At: Jean-Christophe Helary wrote: > > Bob Proulx wrote: > > You might give Isearch+ a try and report back with your experiences with it. > > Not before I've convinced myself that it's the only solution left :) :-) I applaud you sticking to it. I understand the sentiment to limit the customization. > > I think here there is a misunderstanding. "C-s party M-% RET" will > > search for "party" and then delete it. > > Ok, you mean: "C-s party M-% RET ." (the period is omitted here but > you put it later in your reply and I could not get the right result > without it. Oops. Yes. Need the '.' there. It is hard for me to transcribe interactive commands that I type reflexively without thought into documentation. I miss things that I type without thinking about them. But on the plus side those things do not limit me either. The ones that frustrate me are the tedious ones that I can't type in. (For example C-M-% from an ssh text terminal.) > That works, but that's still a lot more keys than something like: > C-s party (some key to indicate that the target is the matching string) delete Agreed. But as I had said before language shapes the way you think. Since that hasn't been an editor capability for me I haven't been thinking I wanted to do it in exactly that way. Also the "other" editor vi/vim doesn't have a paradigm for it either. In those I would have the point at the start of the match and would likely "dw" (delete word forward), or count up and day 5dw to delete five words forward, until I had deleted what I wanted to delete. To be honest most of the time in emacs I would search to the end of the string I want to delete. Then I would put my left thumb on Alt and press Backspace for M-DEL and delete words backward until I had deleted what I wanted to delete. It hasn't been one of the things I have wanted to speed up. (I do have one of those. I'll post that in a different thread.) > Which is also a lot more keys than: > C-something party delete (where "something" would call a "catch a match" thingy) For me I use isearch for navigation *all of the time* and I count on leaving the mark behind at the previous location. Then depending upon what I want I can either C-SPC to pop the mark or C-x C-x to exchange the point and mark, either way, and return to the previous location. Setting the mark at the beginning of the match would get in the way for me. I could possibly live with it as an additional mark and get used to typing in C-SPC an additional time. [[Aside: Except on Android I haven't found a way to enter C-SPC. It seems to be a missing capability. Frustrates me every time I try to use Android as a terminal.]] > > Hope this helps! :-) > > It did, but I'm not yet where I want to be :-) I think in the end you will want/need some custom elisp that creates this behavior for you. That is part of the joy of emacs. Being able to customize and extend it. Just don't mess it up for the rest of us! :-) > But I'm slowly getting there. It looks like this "catch a match" > properly implemented as not conflicting with the current behavior > would be a nice addition to (at least my) emacs. Go for it! Bob