From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#34525: replace-regexp missing some matches Date: Sun, 24 Feb 2019 17:37:46 +0000 Message-ID: <20190224173746.GA21808@ACM> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35736"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: daniel.lopez999@gmail.com, Stefan Monnier , 34525@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 24 18:43:13 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 1gxxo0-0009DN-Ma for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Feb 2019 18:43:12 +0100 Original-Received: from localhost ([127.0.0.1]:53872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxxnz-0005Rk-Lv for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Feb 2019 12:43:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxxns-0005Rb-Iv for bug-gnu-emacs@gnu.org; Sun, 24 Feb 2019 12:43:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxxnr-0001ml-M9 for bug-gnu-emacs@gnu.org; Sun, 24 Feb 2019 12:43:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxxnq-0001mL-Co; Sun, 24 Feb 2019 12:43:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gxxnq-0005Hg-23; Sun, 24 Feb 2019 12:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 24 Feb 2019 17:43:02 +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.155103014220269 (code B ref 34525); Sun, 24 Feb 2019 17:43:02 +0000 Original-Received: (at 34525) by debbugs.gnu.org; 24 Feb 2019 17:42:22 +0000 Original-Received: from localhost ([127.0.0.1]:50406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxxnB-0005Gp-IZ for submit@debbugs.gnu.org; Sun, 24 Feb 2019 12:42:21 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:25849 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gxxn5-0005Gb-FU for 34525@debbugs.gnu.org; Sun, 24 Feb 2019 12:42:16 -0500 Original-Received: (qmail 86828 invoked by uid 3782); 24 Feb 2019 17:42:10 -0000 Original-Received: from acm.muc.de (p2E5D538C.dip0.t-ipconnect.de [46.93.83.140]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 24 Feb 2019 18:42:09 +0100 Original-Received: (qmail 21852 invoked by uid 1000); 24 Feb 2019 17:37:46 -0000 Content-Disposition: inline In-Reply-To: <83bm35hkqo.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:155720 Archived-At: Hello, everybody. On Thu, Feb 21, 2019 at 05:40:47 +0200, Eli Zaretskii wrote: > > Date: Wed, 20 Feb 2019 21:30:03 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > > Maybe look at this from a different angle: what do we have in C++ mode > > > that isn't present in C mode, and could potentially affect this use > > > case? > > Well, the most obvious thing is the category text property whose value > > is the symbol c-<-as-paren-syntax. This symbol's plist is > > (risky-local-variable t syntax-table (4 . 62)) > > . I can't think of anything else at the moment. > If you remove that, does the problem go away? I'm afraid I didn't get around to trying that. But I've been busy with GDB. 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". Since this syntax, (4 . 62) is not the start of a word, re_match_2_internal returns a failure result. 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. I tested this theory by putting a space between the Bitmap and <, and attempting a query-replace of Bitmap with 1234567Bitmap. The error still occurred. In this buffer, the original replacement then appears to work. -- Alan Mackenzie (Nuremberg, Germany).