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#36136: [PATCH]: Re: bug#36136: syntax-ppss fails to invalidate its cache on changes to syntax-table text properties Date: Thu, 13 Jun 2019 12:21:50 +0000 Message-ID: <20190613122150.GA25866@ACM> References: <20190608131724.GA4643@ACM> <20190609183912.GA17965@ACM> <20190612101503.GA4587@ACM> 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="136692"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 36136@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 13 15:56:06 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 1hbQD0-000ZOW-GE for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jun 2019 15:56:06 +0200 Original-Received: from localhost ([::1]:39866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbQCy-0004f5-UP for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jun 2019 09:56:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33913) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hbOkA-000280-Cj for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 08:22:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hbOk2-0002nL-6x for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 08:22:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49368) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hbOjx-0002jl-Qy for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 08:22:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hbOjx-0001KP-KZ for bug-gnu-emacs@gnu.org; Thu, 13 Jun 2019 08:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Jun 2019 12:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36136 X-GNU-PR-Package: emacs Original-Received: via spool by 36136-submit@debbugs.gnu.org id=B36136.15604285185094 (code B ref 36136); Thu, 13 Jun 2019 12:22:01 +0000 Original-Received: (at 36136) by debbugs.gnu.org; 13 Jun 2019 12:21:58 +0000 Original-Received: from localhost ([127.0.0.1]:34679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hbOju-0001K6-JA for submit@debbugs.gnu.org; Thu, 13 Jun 2019 08:21:58 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:47516 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hbOjs-0001Jx-Fi for 36136@debbugs.gnu.org; Thu, 13 Jun 2019 08:21:57 -0400 Original-Received: (qmail 33436 invoked by uid 3782); 13 Jun 2019 12:21:50 -0000 Original-Received: from acm.muc.de (p4FE15E04.dip0.t-ipconnect.de [79.225.94.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 13 Jun 2019 14:21:50 +0200 Original-Received: (qmail 25924 invoked by uid 1000); 13 Jun 2019 12:21:50 -0000 Content-Disposition: inline In-Reply-To: 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:160490 Archived-At: Hello, Stefan. On Wed, Jun 12, 2019 at 06:54:25 -0400, Stefan Monnier wrote: > >> Hmm... I'm not too fond of adding ad-hoc support for specific > >> text-properties in (set_properties, add_properties, remove_properties). > > Neither am I, particularly. But the whole point of syntax-ppss, surely, > > is that it should work automatically, without users having to call > > syntax-ppss-flush-cache all the time. > `grep` seems to argue that "all the time" is an over statement. CC Mode has to call that function all the time, without any scare quotes. In particular, it has to call the thing before each font-locking action. It shouldn't have to; it doesn't even make any use of the package, and is thus messy programming indeed. The root of the problem is the implicit assumption made by syntax-ppss that programs would never set syntax-table properties. This assumption doesn't hold. [ .... ] > > It will probably not make a great deal of difference either way. Buffer > > changes are frequent in Emacs, and so are calls to syntax-ppss in many > > major modes. > That's also my impression (which is why I haven't bothered to make > syntax-ppss-flush-cache lazy like your patch does, even tho I've been > tempted to several times). > > Well, for CC Mode I'm going to have to do that anyway, since Emacs-26.x > > and earlier are already out there and aren't going to change. > Indeed. > [ unless you decide to make CC-mode use syntax-propertize, of course ;-) ] I don't think that would work without loss of functionality and loss of speed (to whatever degree), and even if it could, would be more work than it's worth. > But I also agree that it shouldn't prevent us from looking for > better solutions. What about my idea of giving a "no inhibit" property to functions on before/after-change-functions? This would be easy to implement, though might have unwanted unexpected consequences. > > This is going to be tedious and error prone. > I don't see why. Usually a single call does the trick (as seen above: > either in the function that sets the syntax-table property, or in the > function that takes care of refreshing things in response to a buffer > modification). Yes, you're right, it wasn't too bad. There are many functions in CC Mode which set the syntax-table property, so adapting each of them didn't come into consideration. I amended the existing cache invalidation routine to keep track of a syntax-table property position, and pass that position to syntax-ppss-flush-cache at the end of c-after-change, just before font-lock kicks in. But, as already said, I shouldn't have to do this. > Stefan -- Alan Mackenzie (Nuremberg, Germany).