bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#27896: [External] : Re: bug#27896: 25.2; `C-M-%' with `rectangle-mar


From: Drew Adams
Subject: bug#27896: [External] : Re: bug#27896: 25.2; `C-M-%' with `rectangle-mark-mode'
Date: Fri, 5 Feb 2021 16:19:06 +0000

Thanks for looking at this feature request.

> > The (normal) region limits the text that replacement search
> > tries to match, by bounding it.  The rectangular region keeps
> > the ordinary region as the domain of text that search tries
> > to match, and it filters the matches against that domain to
> > remove any matches that are not wholly within the limits of
> > the rectangle.
> 
> Yup.  It's a pretty odd design decision, though --
> I wonder whether it this happened on purpose or
> whether that was just the simplest way to implement this.

I'm pretty sure it was done this way just because
that's much simpler to do.  Filtering is after
the fact - after matching.  And matching respects
only the buffer restriction (`point-(min|max)').

In search+.el I make it possible (via an option)
to actually limit search to the active region.
That is, search matches cannot extend beyond the
region limits.

That feature required quite a few changes to the
Isearch code, even if most of them were simple.

(The general idea is to bind two vars for active
region begin and end and respecting the option,
and then replace calls to `point-(min|max)' by
those vars.  IOW, instead of limiting search to
the buffer restriction, limit it to the region.)

What this request is about amounts to doing
something similar, but doing that with all of the
begin and end bits of a noncontiguous region.

I haven't yet had the time (or motivation) to do
that in my code.

I think it would greatly help Emacs to have such
a feature, i.e., to truly treat the limits of each
zone of a noncontiguous region as search limits.

Now, a question arises as to whether, if we did
have such a feature, it would _also_ be good to
still have the behavior that we have now, i.e.
still be able to have a filter work on matches
for the full buffer, that is, to _not_ limit the
search tries to the region.

I'm guessing that it _would_ be good to conserve
the current behavior, i.e., to have a variable
that chooses which behavior to use.  But I don't
have a good idea of why I think both can be useful.

One reason to keep (also) the current behavior
might be backward compatibility, of course.  But
my gut whispers that there are other reasons.
I haven't really thought about it much.

> I've added Juri to the CCs; perhaps he can clarify.
> (The problem is that if you ask to replace "foo.*bar", and you have
>   foo bar bar
> then `query-replace' will match the entire line, and then filter out
> that match (given that we have a rectangular region that covers just
> "foo bar") and not replace anything.)

It's more important than that.  But yeah, that at
least illustrates one difference.

The point is this: the search boundaries are
currently `point-min' and `point-max', which
respect only narrowing.  If you want to limit
search to a region then you need to narrow to it.

With isearch+.el you can have search respect the
region limits without narrowing (so you can see
the surrounding text while searching - you can
even optionally dim that surrounding text).

And in this case the region bounds act just like
the buffer bounds: _matching_, itself, (not just
filtering) is limited to the region text.

Also with Isearch+ you can search a set of zones,
i.e., a noncontiguous region (while showing or
hiding the antizones).  But in this case, the
limits of those region pieces (zones) aren't used
for matching; they're used only for filtering.

IOW, with my code searching within zones has the
same fault that vanilla Isearch has for searching
within a region using a filter that restricts to
the region: it _matches_ beyond what should be
the search space, and _then it filters_ out any
matches that extend beyond the search space.

In a nutshell, the requested feature is to be
able (but not be required) to not only _filter_
out matches that go beyond zone limits but also
to not allow those matches in the first place.
That is, _limit matching_ itself to be within
such bounds.

(Note: a noncontiguous region need not be
rectangular.  This feature would apply to any
sequence of buffer zones.)





reply via email to

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