Hi Juri, Did you open it with TERM="xterm-256color"? Best, Jayden On Sun, Jun 23, 2019 at 2:41 PM Juri Linkov wrote: > >> Until this is officially fixed I've come up with the following > workaround, > >> going off of the details you provided: > > > >> I created a "replace_fixed.el" file in "~/.emacs.d/lisp/" that is > >> replace.el taken from > >> > https://raw.githubusercontent.com/emacs-mirror/emacs/emacs-26/lisp/replace.el > >> with > >> the following diff: > > > >> diff --git a/replace.el b/replace_fixed.el > >> index 08feb8e..8280fdd 100644 > >> --- a/replace.el > >> +++ b/replace_fixed.el > >> @@ -2227,7 +2227,7 @@ It is called with three arguments, as if it were > >> (isearch-forward (not backward)) > >> (isearch-other-end match-beg) > >> (isearch-error nil)) > >> - (isearch-lazy-highlight-new-loop range-beg range-end)))) > >> + (save-match-data (isearch-lazy-highlight-new-loop range-beg > >> range-end))))) > > > >> (defun replace-dehighlight () > >> (when replace-overlay > > > >> Then I added the following to my "~/.emacs", restarted my emacs server, > and > >> the issue was gone!: > > > >> (load-library "~/.emacs.d/lisp/replace_fixed.el") > > > >> This probably isn't the proper fix, but just thought I'd share in case > >> anyone else is experiencing this and wanted a temporary workaround. > > > > Excellent! To be honest, I was thinking of sending just that workaround > > to you as a temporary patch, but it seems I didn't need to. :-) > > > > That might well be the fix we end up putting into Emacs, but it might > > not be. Sorry we're so slow, here. > > I think first we should try to narrow down the source of this match data > leak. > Then we could decide what is the best solution. Currently I see no such > place > in isearch-lazy-highlight-new-loop that calls external code. OTOH, while > looking at CC-Mode I noticed that it does some matches on before-change > hooks. > I could debug it but can't reproduce neither in 26.1 nor in 27, even with > -Q -nw. >