GNU bug report logs - #77121
[PATCH] Make isearch highlight overlays non-sticky (non-advance) at both ends

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77121 in the body.
You can then email your comments to 77121 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sora Takai <SoraTakai <at> protonmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Re: [PATCH] Make isearch highlight overlays non-sticky (non-advance)
 at both ends
Date: Wed, 19 Mar 2025 14:57:31 +0000

[Message part 1 (text/plain, inline)]

Sorry, here is an updated patch. I think this is enough since it is for the most part lazy-highlights with (setq isearch-lazy-highlight t)​ and (setq lazy-highlight-cleanup nil)​ that matter for editing.

On Wednesday, March 19th, 2025 at 11:10 PM, Sora Takai <SoraTakai <at> protonmail.com> wrote:

> Tags: patch
>
> Hi,
>
> here is a simple patch to make isearch highlights non-sticky at both ends (i.e. no front and rear advance on overlays), thereby making them more intuitive and less bothersome for further editing. Currently, every isearch overlay, including lazy highlights, inherits isearch highlight color when you type characters at front and rear positions. By applying this patch, users will no longer get that color stickiness when editing around isearch highlights, which makes them more 'self-contained'.
>
> (This is the first time I am submitting a patch to this community - apologies in advance if I am not following the conventions in some way.)

[Message part 2 (text/html, inline)]

[0001-Make-isearch-lazy-highlights-non-sticky-at-both-ends.patch (application/octet-stream, attachment)]

Message #8 received at 77121 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sora Takai <SoraTakai <at> protonmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: 77121 <at> debbugs.gnu.org
Subject: Re: bug#77121: [PATCH] Make isearch highlight overlays non-sticky
 (non-advance) at both ends
Date: Thu, 20 Mar 2025 14:29:00 +0200

> Date: Wed, 19 Mar 2025 14:57:31 +0000
> From:  Sora Takai via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Sorry, here is an updated patch.  I think this is enough since it is for the most part lazy-highlights with (setq
> isearch-lazy-highlight t)​ and (setq lazy-highlight-cleanup nil)​ that matter for editing.
> 
> On Wednesday, March 19th, 2025 at 11:10 PM, Sora Takai <SoraTakai <at> protonmail.com> wrote:
> 
>  Tags: patch
> 
>  Hi, 
> 
>  here is a simple patch to make isearch highlights non-sticky at both ends (i.e. no front and rear
>  advance on overlays), thereby making them more intuitive and less bothersome for further editing. 
>  Currently, every isearch overlay, including lazy highlights, inherits isearch highlight color when you
>  type characters at front and rear positions.  By applying this patch, users will no longer get that color
>  stickiness when editing around isearch highlights, which makes them more 'self-contained'.
> 
>  (This is the first time I am submitting a patch to this community - apologies in advance if I am not
>  following the conventions in some way.)

Thanks.

Juri, any comments or suggestions?

Message #11 received at 77121 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77121 <at> debbugs.gnu.org, Sora Takai <SoraTakai <at> protonmail.com>
Subject: Re: bug#77121: [PATCH] Make isearch highlight overlays non-sticky
 (non-advance) at both ends
Date: Fri, 21 Mar 2025 09:50:35 +0200

>>>  here is a simple patch to make isearch highlights non-sticky at both ends (i.e. no front and rear
>>>  advance on overlays), thereby making them more intuitive and less bothersome for further editing. 
>>>  Currently, every isearch overlay, including lazy highlights, inherits isearch highlight color when you
>>>  type characters at front and rear positions.  By applying this patch, users will no longer get that color
>>>  stickiness when editing around isearch highlights, which makes them more 'self-contained'.
>>
>> Sorry, here is an updated patch.  I think this is enough since it is for the most part lazy-highlights with (setq
>> isearch-lazy-highlight t)​ and (setq lazy-highlight-cleanup nil)​ that matter for editing.
>
> Thanks.
>
> Juri, any comments or suggestions?

It would be nice to have a step-by-step recipe for this case
since I don't understand how to reproduce this problem.

Message #14 received at 77121 <at> debbugs.gnu.org (full text, mbox):

From: Sora Takai <SoraTakai <at> protonmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77121 <at> debbugs.gnu.org
Subject: Re: bug#77121: [PATCH] Make isearch highlight overlays non-sticky
 (non-advance) at both ends
Date: Fri, 21 Mar 2025 09:31:34 +0000

Thanks for taking a look, Juri.

These are the steps to reproduce it:

1. Evaluate

;; Enable lazy-highlight
(setq isearch-lazy-highlight t)

2. Evaluate

;; Keep lay-highlights even after isearch finishes
(setq lazy-highlight-cleanup nil)

3. On some writable buffer, evaluate

(progn
  (insert "emacs")
  (beginning-of-buffer))

4. M-x isearch-forward RET emacs RET

5. Evaluate `(backward-word)` (M-b)

6. Type "GNU "

7. With this patch, you won't get the same lazy highlight color inherited on "GNU " string ('non-sticky' behavior); without it, you will inherit the same highlight color on additional "GNU " string ('sticky' behavior).

8. Now the opposite end: evaluate `(beginning-of-buffer)` and do (4) again.

9. Type " rocks."

10. with this patch, you won't get the same lazy highlight color inherited on " rocks." string; without it, you'll get the same highlight color.


On Friday, March 21st, 2025 at 4:50 PM, Juri Linkov <juri <at> linkov.net> wrote:

> > > > here is a simple patch to make isearch highlights non-sticky at both ends (i.e. no front and rear
> > > > advance on overlays), thereby making them more intuitive and less bothersome for further editing.
> > > > Currently, every isearch overlay, including lazy highlights, inherits isearch highlight color when you
> > > > type characters at front and rear positions. By applying this patch, users will no longer get that color
> > > > stickiness when editing around isearch highlights, which makes them more 'self-contained'.
> > > 
> > > Sorry, here is an updated patch. I think this is enough since it is for the most part lazy-highlights with (setq
> > > isearch-lazy-highlight t) and (setq lazy-highlight-cleanup nil) that matter for editing.
> > 
> > Thanks.
> > 
> > Juri, any comments or suggestions?
> 
> 
> It would be nice to have a step-by-step recipe for this case
> since I don't understand how to reproduce this problem.

Message #17 received at 77121 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sora Takai <SoraTakai <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77121 <at> debbugs.gnu.org
Subject: Re: bug#77121: [PATCH] Make isearch highlight overlays non-sticky
 (non-advance) at both ends
Date: Sat, 22 Mar 2025 21:17:50 +0200

forcemerge 77120 77121
close 77121 31.0.50
thanks

> These are the steps to reproduce it:

Thanks for the detailed instructions.
Now I see that this is a known problem.
I encounter it frequently, but
didn't see a way to fix this because often
I need to add new text in the middle the overlay.

But it would be nice to fix it at least for front positions.

> 10. with this patch, you won't get the same lazy highlight color
> inherited on " rocks."  string; without it, you'll get the same
> highlight color.

Actually, the color is not inherited at the rear position even
without your patch.  So your patch fixes only the front position.

>>> Sorry, here is an updated patch. I think this is enough since it is for the most part lazy-highlights with (setq
>>> isearch-lazy-highlight t) and (setq lazy-highlight-cleanup nil) that matter for editing.

Thanks for the patch.  Now it's pushed to master.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.