From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: killing the result of isearch Date: Fri, 10 Nov 2017 08:54:33 -0800 (PST) Message-ID: <7c7b0606-d33e-42eb-b0f6-2629b45e6728@default> References: <433bd3d0-a506-4d89-9d10-dcbfb0e23be0@default> <852BAA28-2A50-4AD9-B8D6-9F06905A4395@gmail.com> <87r2tava5x.fsf@hornfels.zedat.fu-berlin.de> <87y3nigy86.fsf@hornfels.zedat.fu-berlin.de> <87wp32f7os.fsf@hornfels.zedat.fu-berlin.de> <29AEE45F-D0CA-442F-8F46-E290C40782B4@gmail.com> <87k1z02yth.fsf@fliptop> <4EA90B44-DF92-43C3-B8D0-6C42D1D6F1DA@gmail.com> <87h8u32kw6.fsf@fliptop> <2348DA86-8BEF-46E5-A19D-DE8306D47D95@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510332911 24920 195.159.176.226 (10 Nov 2017 16:55:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Nov 2017 16:55:11 +0000 (UTC) To: Jean-Christophe Helary , Help Gnu Emacs mailing list Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Nov 10 17:55:04 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 1eDCa5-0005za-II for geh-help-gnu-emacs@m.gmane.org; Fri, 10 Nov 2017 17:55:01 +0100 Original-Received: from localhost ([::1]:42533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDCaC-0004do-PC for geh-help-gnu-emacs@m.gmane.org; Fri, 10 Nov 2017 11:55:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDCZn-0004dh-7F for help-gnu-emacs@gnu.org; Fri, 10 Nov 2017 11:54:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDCZk-0002Oh-48 for help-gnu-emacs@gnu.org; Fri, 10 Nov 2017 11:54:43 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:21630) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDCZj-0002NQ-Rg for help-gnu-emacs@gnu.org; Fri, 10 Nov 2017 11:54:40 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAAGsaxZ004236 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Nov 2017 16:54:37 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAAGsYmG022177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Nov 2017 16:54:35 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAAGsYSf010233; Fri, 10 Nov 2017 16:54:34 GMT In-Reply-To: <2348DA86-8BEF-46E5-A19D-DE8306D47D95@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 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:114840 Archived-At: > The problem here is that the result of search is > *only* to move point and *not* to create a region of the highlighted > matching string. So what appears on the screen carries actually very > little meaning *because* with vanilla emacs, there is not isearch > function (or any other search function for that matter) that creates a > region out of that match. Not to belabor this too much, but `query-replace' sounds like it might be something closer to what you are looking for. It is exactly about finding some text and _optionally_ replacing or deleting it. `RET' just finds it and exits. `.' replaces/deletes it and exits. `C-w' deletes it and exits. `SPC' replaces/deletes it and moves to the next occurrence. `!' replaces/deletes all occurrences. You can move backward, undo, and change replacement string. `query-replace' is _designed to act_ on the highlighted text (the matches). Isearch is _not_ designed to act on it. (But Isearch+ also let you do that, and in any number of ways.) The strength of Isearch is the "I" part: _incremental_ changes to the search string are reflected in the matches. That behavior is not really available to `query-replace', except in a roundabout, clumsy way - it was designed for incremental replacement decisions, but not for incrementally changing the search pattern. > So it really is only a decoration. Mere "decoration", if you like. But it's decoration with a lot of meaning. It _shows you what matches_ your search pattern. How else would you know what matches? Is seeing the targets clearly just decoration, or is it an important feature? > If something should be highlighted, it should be the position > of point, not how point found its way there, or at least the > full region created by the search. Dunno what you mean by the last part. What full region are you suggesting might be useful to highlight? Do you mean the region from the current search hit back to where search started? If you just mean full search hits then that's the longstanding behavior. > Anything else has little meaning in the context of isearch. I disagree strongly here. For search the _most important_ things to highlight (point out in some way) are the search hits. If I show you an aerial photo of a region, and you ask for the locations of the cafes (or churches or playgrounds or restrooms) don't you think it would be helpful for me to highlight them for you? Which also points out that Isearch is _not_ just about navigation - moving to some search-hit location. It's also - perhaps mainly - about identifying/seeing the search hits. It's about pointing them out: highlighting them. That's what I use it for much of the time, when working with code, for example. Whether I end up moving to any search hit, even temporarily, is a separate thing. Just being able to see clearly the matches is often all I need. That many other-application "find" operations highlight only the current search hit is a drawback, IMO, not an advantage. And seeing all of the search hits in the current window is especially important for an _incremental_ search operation, where you often change the search pattern. If you keep to the same search pattern throughout a static "find" operation then perhaps it's not so important to highlight all of the search hits. Meaning no offense, I'd suggest (in hopes that it helps) that your reaction here sounds a bit like that of someone encountering a frying pan for the first time and complaining that it is not as good as a deep pot for boiling water. A frying pan is its own thing. Incremental search is a thing. It has its own features and advantages. It's not the only way to find things, and it was not designed as a way to find and act on something. It's still useful, as designed. But Emacs offers plenty of other ways to find things and act on them, from `query-replace' to `grep' and `occur', and on beyond. Most importantly, you can roll your own - limited only by one's imagination.