[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: killing the result of isearch

From: Bob Proulx
Subject: Re: killing the result of isearch
Date: Tue, 7 Nov 2017 21:27:21 -0700
User-agent: NeoMutt/20170609 (1.8.3)

Jean-Christophe Helary wrote:
> I've tried again the default behavior in the editor where I usually
> do my regex search/replaces (BBEdit) and the only (and major)

I have never used BBEdit and therefore am at a disadvantage in
comparing behaviors.  But perhaps someone else will have used it and
have suggestions.

> difference is where the mark is put at the beginning of the
> search. In emacs it is put where the point is at the beginning of
> the search, in BBEdit it is put at the beginning of the match, so
> the region "matches" the search match.

Yes.  A fundamental difference.  But wasn't that one of the
advantagess of Isearch+?  I recall Drew and another saying that the
additional Isearch+ functionality included the ability to set the mark
around the matched text.  In this case it would leave the mark at the
start of the match and the point at the end of the match which would
create the region between and be exactly what you are saying you are
wanting.  You might give Isearch+ a try and report back with your
experiences with it.

> Now, I'm not going to argue about which is best, because the designs
> are different, as Stephan wrote, search in emacs finds a location
> and allows the user to act on that location while finding the match
> is not the purpose but just the means to accomplish that, while in
> BBEdit finding the match is the purpose of the function.

Right.  They started from different starting points and ended up at
different ending points and we the users are seeing the tools
available and selecting the best one from the set from our
perspective.  Just different.

But emacs can be customized to work the way you want.

> > The answers suggesting M-% are excellent suggestions.
> Not really, because if I know what kind of regex I'm looking for, I
> don't always know how I want to change the match, that depends on
> context, and overwriting a selection is very often more efficient
> than going through a replace hoop.

I think here there is a misunderstanding.  "C-s party M-% RET" will
search for "party" and then delete it.  Start by searching.  In this
case it is an interactive search and therefore you get feedback and
interactively react to it.  Then if you decide to delete the matching
string at that moment type M-% RET from *within* an isearch will
replace the matched text with nothing.  This is different and separate
from M-% standalone *outside* of an isearch.  Outside of it you are
right that you don't know what you will see yet and don't know what
you might decide after you see it.  But within an isearch you will see
what is being matched and might decide to delete it and one way is to
use M-% at that moment which will preload the previous search string
into the match.  I'm being very tedious and explicit here because I
feel that this particular part might have been missed in the previous

  Went up the hill to fetch a pail of water.
  C-s SPC of SPC water M-% RET .
  Went up the hill to fetch a pail.

This contains some subtle points of isearch.  Let me break that apart.

  C-s SPC of SPC water

Start an incremental search.  Type in the string I want to match.
Stay in incremental search and type in M-%.  The details can be found
in the documentation.

While the incremental search is active type in M-% (which the easy
keystrokes for me are ESC Shift-%).  From the manual:

       Typing ‘M-%’ in incremental search invokes ‘query-replace’ or
    ‘query-replace-regexp’ (depending on search mode) with the current
    search string used as the string to replace.  A negative prefix argument
    means to replace backward.  *Note Query Replace::.

Typing "C-s SPC of SPC water" followed by M-% executes this
query-replace from within isearch and preloads the search pattern
prompting you for the replacement pattern.  RET without entering a
replacement sets it to empty effectively deleting it.  Then you are in
interactive query replace mode.  Query replace is documented:

The most natural thing would be to hit SPC to make the replacement in
the incremental search.  Then if there are more occurrences further
down it will proceed through all further occurrences.

But if you don't want to replace anything further down the file, want
to replace just that one thing and stop, then '.' is the best way.

    ‘. (Period)’
         to replace this occurrence and then exit without searching for more

Therefore my trace above is using '.' to replace just that one
occurrence and then stop.

Hope this helps! :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]