[Top][All Lists]

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

RE: [External] : Re: Simple isearch concerns

From: Drew Adams
Subject: RE: [External] : Re: Simple isearch concerns
Date: Mon, 5 Apr 2021 15:08:09 +0000

> >> Swiper provides this option and after trying it I found it very
> >> useful and some other users seems they do too.
> >
> > I strongly suspect that swiper does not provide *exactly* that option.
> > E.g. does Swiper's option also cause C-r foo RET to place point at the
> > *end* of "foo" rather than its beginning?
> Just for completeness:
> The original swiper and swiper-backward commands either always leave
> point at the end of the match (by default), or always at the start
> (after customising swiper-goto-start-of-match), regardless of direction.
> Later came swiper-isearch and swiper-isearch-backward, for handling
> multiple matches per line.  AFAICT the former always leaves point at the
> end, and the latter always at the start.
> AFAIK neither of these interfaces was originally designed with a way of
> customising where to leave point in mind; it was an afterthought, and
> naturally there are open bug reports about their behaviour.

FWIW, with isearch+.el forward and backward search
mirror each other in this regard.  Point isn't moved,
and the search hit is selected as the active region.

So point remains in "front" of mark in the direction
of search (which is helpful for repeated search, for

The main use case is wanting to act on the search hit,
not just to move to its other end.  Having mark at the
other end gives you easy access to it, as a freebie.

And yes, I think that if someone really wants to just
move point to the other end of the hit then `C-r RET'
is just fine for that.

I definitely wouldn't advise wasting a key binding
such as `C-RET' on that.  But that's just me, becoming
a bindings conservationist in my old age.

reply via email to

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