From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jayden Navarro Newsgroups: gmane.emacs.bugs Subject: bug#36328: 26.2; Args out of range on search-and-replace of *.cc file Date: Sun, 23 Jun 2019 14:42:48 -0700 Message-ID: References: <20190622132549.84518.qmail@mail.muc.de> <20190622205033.GA9167@ACM> <20190623122207.GA4736@ACM> <20190623193258.GB4736@ACM> <87k1dc2e5h.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005c22b5058c0494b2" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="261020"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Alan Mackenzie , 36328@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 23 23:44:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hfAHS-0015nC-FG for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Jun 2019 23:44:10 +0200 Original-Received: from localhost ([::1]:46848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfAHR-0007Be-GG for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Jun 2019 17:44:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35478) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfAHL-0007BV-RJ for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2019 17:44:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hfAHK-0001JI-GS for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2019 17:44:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41578) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hfAHK-0001IK-3e for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2019 17:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hfAHK-00016G-0a for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2019 17:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jayden Navarro Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jun 2019 21:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36328 X-GNU-PR-Package: emacs Original-Received: via spool by 36328-submit@debbugs.gnu.org id=B36328.15613261894120 (code B ref 36328); Sun, 23 Jun 2019 21:44:01 +0000 Original-Received: (at 36328) by debbugs.gnu.org; 23 Jun 2019 21:43:09 +0000 Original-Received: from localhost ([127.0.0.1]:55117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfAGT-00014N-37 for submit@debbugs.gnu.org; Sun, 23 Jun 2019 17:43:09 -0400 Original-Received: from mail-lf1-f54.google.com ([209.85.167.54]:35954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hfAGQ-00013r-Iq for 36328@debbugs.gnu.org; Sun, 23 Jun 2019 17:43:07 -0400 Original-Received: by mail-lf1-f54.google.com with SMTP id q26so8565380lfc.3 for <36328@debbugs.gnu.org>; Sun, 23 Jun 2019 14:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yugabyte-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFmRXBFARJKN8+9hS/s3f+5/YeyGXVqOqrJSn/IAZA0=; b=eCVIzWBSTMfAS+fN8/YjLXtkhSftuoFPlXFsEGFD433ezOv66HGyrG/VrsEjgWgWAE xuzJrJT/SkGAOITOaJVuMi1x1j7hTF/Rzv3NIALmXS7UEk7FVIDn0o5I/ENtazQ8YMii YkR40GWhrR83NVkBEYcbM+fjUREXwHlvHPC00A6IoyXk4A3fMaJMFj81kds+gMGxd4Yx vPhP+bBGkcYsAepeh4Z1EDipifiWfGUEV6Z4Gd14YabPWW2ApLm8f22Icz8VRYEHfDTG lvJVW+0OuhAAl7u0SqSn2o+6T7rBfSWhlTqFRglxLGrSET+/HSzg0ZJNQv8zIAUloaLn 3azw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFmRXBFARJKN8+9hS/s3f+5/YeyGXVqOqrJSn/IAZA0=; b=qJGzAanhMNABQCeuBGMZX2JF7r38vI8vOiQaoIIpGcFk7DITFdGQL0vSJI2gYup3q1 ucix6tDtN9jeJ1tiPhZ8/klsls8B79jC/HzQgEAkihRaRnAv0/SPa/6Af8193F0xNtrb J7B/TDAFwx1GdDzIpQSP7lijjkEvWPNDYaHHXZGfO/59HgGAmUaYYqr/pQD/5g+29/Gl aKgleXE0FHXRAfDQSQuudR8QPILtl2pclFLx/9g2OglUdEYYRoTooadPA8BMiVl26w1J CNQeV1heylNbuMcuVvObkKJ+BC+fXigwCmKEjIIFLSy7RdYmWxwD7WWYx5hdqpjfJaTy UwKA== X-Gm-Message-State: APjAAAWH3/pWgDy6RzS9V5KbonVUrWwj6Q8FXEXEuhEtB0k0KNh2y4u6 E7WbRyZILHHHUVHCRSlfKPtn7hkCDdmrjWxZX6L92A== X-Google-Smtp-Source: APXvYqyvs/IVcqK6EviWczhug1U4EdrVTGN78CoufSFR8KybQdaZsjfJvSPGxcwg8qnRWl/h4gm5LD9vp6jjJzo9CKw= X-Received: by 2002:a19:8c06:: with SMTP id o6mr9764315lfd.176.1561326180372; Sun, 23 Jun 2019 14:43:00 -0700 (PDT) In-Reply-To: <87k1dc2e5h.fsf@mail.linkov.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161178 Archived-At: --0000000000005c22b5058c0494b2 Content-Type: text/plain; charset="UTF-8" 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. > --0000000000005c22b5058c0494b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juri,

Did you open it with TERM=3D&q= uot;xterm-256color"?

Best,
Jayden


On Sun, Jun 23, 2019 at 2:41 PM Juri Linkov &= lt;juri@linkov.net> 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.gi= thubusercontent.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
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(isearch-forward (n= ot backward))
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(isearch-other-end = match-beg)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(isearch-error nil)= )
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0(isearch-lazy-highlight-new-loop range= -beg range-end))))
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0(save-match-data (isearch-lazy-highlig= ht-new-loop range-beg
>> range-end)))))
>
>>=C2=A0 (defun replace-dehighlight ()
>>=C2=A0 =C2=A0 (when replace-overlay
>
>> Then I added the following to my "~/.emacs", restarted m= y 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 s= hare in case
>> anyone else is experiencing this and wanted a temporary workaround= .
>
> Excellent!=C2=A0 To be honest, I was thinking of sending just that wor= karound
> to you as a temporary patch, but it seems I didn't need to.=C2=A0 = :-)
>
> That might well be the fix we end up putting into Emacs, but it might<= br> > not be.=C2=A0 Sorry we're so slow, here.

I think first we should try to narrow down the source of this match data le= ak.
Then we could decide what is the best solution.=C2=A0 Currently I see no su= ch place
in isearch-lazy-highlight-new-loop that calls external code.=C2=A0 OTOH, wh= ile
looking at CC-Mode I noticed that it does some matches on before-change hoo= ks.
I could debug it but can't reproduce neither in 26.1 nor in 27, even wi= th -Q -nw.
--0000000000005c22b5058c0494b2--