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: Thu, 28 Feb 2019 10:50:25 +0000 Message-ID: <20190228105025.GB4686@ACM> References: <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <20190227173132.GG4772@ACM> <83zhqhjea1.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="221260"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 28 11:56:17 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 1gzJMP-000vRe-DV for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Feb 2019 11:56:17 +0100 Original-Received: from localhost ([127.0.0.1]:36036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzJMO-0006Wu-Bb for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Feb 2019 05:56:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzJMF-0006W7-MD for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2019 05:56:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gzJME-0000yS-Nw for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2019 05:56:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41270) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gzJMA-0000ws-9p; Thu, 28 Feb 2019 05:56:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gzJMA-00048u-6s; Thu, 28 Feb 2019 05:56: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: Thu, 28 Feb 2019 10:56: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.155135132415882 (code B ref 34525); Thu, 28 Feb 2019 10:56:02 +0000 Original-Received: (at 34525) by debbugs.gnu.org; 28 Feb 2019 10:55:24 +0000 Original-Received: from localhost ([127.0.0.1]:54814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzJLY-000486-Fo for submit@debbugs.gnu.org; Thu, 28 Feb 2019 05:55:24 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:20914 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gzJLW-00047w-3H for 34525@debbugs.gnu.org; Thu, 28 Feb 2019 05:55:22 -0500 Original-Received: (qmail 36102 invoked by uid 3782); 28 Feb 2019 10:55:20 -0000 Original-Received: from acm.muc.de (p4FE15DA7.dip0.t-ipconnect.de [79.225.93.167]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 28 Feb 2019 11:55:18 +0100 Original-Received: (qmail 9664 invoked by uid 1000); 28 Feb 2019 10:50:25 -0000 Content-Disposition: inline In-Reply-To: <83zhqhjea1.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:155893 Archived-At: Hello, Eli and Stefan. On Wed, Feb 27, 2019 at 20:07:50 +0200, Eli Zaretskii wrote: > > Date: Wed, 27 Feb 2019 17:31:32 +0000 > > Cc: monnier@IRO.UMontreal.CA, daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > > next_interval and previous_interval are used extensively, so I'm > > > having hard time believing that they have such a blatant bug. > > Yes, how come we haven't seen many more consequences? > > Maybe syntax-table text properties aren't as widely used as all that. > I actually had the text properties in mind. They are used all over > the place. Faces are a feature that would make any such bugs > immediately visible. I think the mechanism with update_interval is only used in syntax.c, and only for the syntax-table property. > > I'm guessing this fix will be deemed too unsafe to make it into the > > emacs-26 release branch. ;-( > That goes without saying. OK. Progress on the bug seems to have stalled somewhat. Now that we understand the cause, one of us needs to decide how to fix it. I think we've discussed the following alternatives: (i) Calculate ->position's in previous_interval and next_interval, as my tentative patch already does. (ii) Calculate the ->position's in update_interval, on moving to parents. (iii) Do away with update_interval, replacing it in syntax.c with previous/next_interval in while loops. At the moment, only (i) has been tried. Speed-wise, it seems not to make any difference in an optimised GNU build, though it did appear to be significantly (~4%) slower on an unoptimised build which scrolls through a C++ file with lots of templates. I don't think it's worth the effort to make a systematic speed comparison between the alternatives. (iv) Additionally, there is a cleanup wanted, where setting ->position in the chain of parents should be moved from update_syntax_table to find_interval. In (i), the convention for ->position would be that it is valid for the target interval together with all its parents. In (ii) and (iii), it would only be valid in the final target intervals found by navigation. I think this should be explicitly stated in a comment in struct interval. So, where do we go from here? If it were up to me, I would probably chose (i), simply because it's already been done, but I've no strong feelings over it. I'm also willing to implement (ii), or even (iii), if that is wanted. In any case, I would ask one of you for a careful code review of my changes - this stuff is easy to get wrong. -- Alan Mackenzie (Nuremberg, Germany).