From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34525: replace-regexp missing some matches Date: Sun, 24 Feb 2019 19:56:13 +0200 Message-ID: <83mumlnk8y.fsf@gnu.org> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="93464"; mail-complaints-to="usenet@blaine.gmane.org" Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 24 18:57:24 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gxy1i-000OCX-Ka for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Feb 2019 18:57:22 +0100 Original-Received: from localhost ([127.0.0.1]:53989 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxy1h-0007J9-Kv for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Feb 2019 12:57:21 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxy1V-0007IC-ET for bug-gnu-emacs@gnu.org; Sun, 24 Feb 2019 12:57:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxy1U-0000n4-59 for bug-gnu-emacs@gnu.org; Sun, 24 Feb 2019 12:57:09 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36882) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxy1N-0000kM-PD; Sun, 24 Feb 2019 12:57:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gxy1N-0005bP-Kh; Sun, 24 Feb 2019 12:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 24 Feb 2019 17:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode Original-Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155103097521481 (code B ref 34525); Sun, 24 Feb 2019 17:57:01 +0000 Original-Received: (at 34525) by debbugs.gnu.org; 24 Feb 2019 17:56:15 +0000 Original-Received: from localhost ([127.0.0.1]:50426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxy0c-0005aP-M3 for submit@debbugs.gnu.org; Sun, 24 Feb 2019 12:56:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxy0b-0005aC-1I for 34525@debbugs.gnu.org; Sun, 24 Feb 2019 12:56:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxy0U-0000Q5-3g; Sun, 24 Feb 2019 12:56:06 -0500 Original-Received: from [176.228.60.248] (port=2939 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gxy0T-0006cn-Nw; Sun, 24 Feb 2019 12:56:06 -0500 In-reply-to: <20190224173746.GA21808@ACM> (message from Alan Mackenzie on Sun, 24 Feb 2019 17:37:46 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:155721 Archived-At: > Date: Sun, 24 Feb 2019 17:37:46 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, > Stefan Monnier > From: Alan Mackenzie > > The query-replace word ends up calling re-search-forward. > Fre_search_forward ends up calling re_search_2 (which is called > rpl_re_search_2 in gdb. :-( ). > > This calls re_match_2_internal, which scans through the compiled regexp, > "\". > > Up till now, we have said yes to replace the first Bitmap with > SharedBitmap in query-replace. Emacs is now seeking out the second > occurrence of Bitmap, which is on L69 of the OP's test file, and looks > like "Bitmap<", where the < has a syntax-table text property of (4 . 62), > an opening paren which matches ">". > > re_natch_2_internal finds its way to case wordbeg: to handle the "\<" of > the regexp. It invokes UPDATE_SYNTAX_TABLE (charpos) to get the syntax > for the "B" it has already found. > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > the current contents of position 1948, but the contents of 1948 before > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > So it picks up the syntax for the "<" rather than the "B". Are you saying that we've modified buffer text, but re_match_2_internal still holds to a C pointer to buffer text before the change? If so, it's a simple manner of recomputing the C pointer using the buffer position after the change, right? We do such things in a few places, like coding.c, by recording the offset of the text before the change and reapplying it after the change. > I think the glitch is in the text property interval handling code. It is > as though after the replacement of Bitmap by SharedBitmap, the interval > starting positions have not been adjusted for the extra six characters. If the code has variables that record C pointers to buffer text, those need to be updated after every change, of else they will become invalid. But I'm surprised we have such blatant bugs in such veteran code, so I'm probably missing something. Can you describe the above again, this time showing the relevant code fragments and variables involved in this? Thanks.