From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result. Date: Mon, 11 Sep 2017 20:12:04 +0000 Message-ID: <20170911201204.GC3605@ACM> References: <83h8wlz1kf.fsf@gnu.org> <20170902174027.GB4267@ACM> <20170907204502.GC4488@ACM> <69e034d3-7a52-cc81-dc56-e5308ad5dce0@yandex.ru> <20170910113626.GB3588@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1505161106 31741 195.159.176.226 (11 Sep 2017 20:18:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2017 20:18:26 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: John Wiegley , Philipp Stephani , 22983@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 11 22:18:21 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drV9m-0007c9-QH for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 22:18:11 +0200 Original-Received: from localhost ([::1]:60354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drV9u-0003Km-3X for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 16:18:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drV9h-0003JK-CF for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 16:18:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drV9e-0005w6-4J for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 16:18:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drV9d-0005w0-VM for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 16:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drV9d-0004q7-Jt for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 16:18: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: Mon, 11 Sep 2017 20:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22983 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22983-submit@debbugs.gnu.org id=B22983.150516104018545 (code B ref 22983); Mon, 11 Sep 2017 20:18:01 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 11 Sep 2017 20:17:20 +0000 Original-Received: from localhost ([127.0.0.1]:34102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drV8y-0004p3-9k for submit@debbugs.gnu.org; Mon, 11 Sep 2017 16:17:20 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:62007 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1drV8v-0004ot-Vs for 22983@debbugs.gnu.org; Mon, 11 Sep 2017 16:17:18 -0400 Original-Received: (qmail 25234 invoked by uid 3782); 11 Sep 2017 20:17:16 -0000 Original-Received: from acm.muc.de (p548C7BC7.dip0.t-ipconnect.de [84.140.123.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 11 Sep 2017 22:17:15 +0200 Original-Received: (qmail 4983 invoked by uid 1000); 11 Sep 2017 20:12:04 -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: 208.118.235.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:136806 Archived-At: Hello, Dmitry. On Mon, Sep 11, 2017 at 03:11:22 +0300, Dmitry Gutov wrote: > On 9/10/17 2:36 PM, Alan Mackenzie wrote: > >>> The solution I propose is to introduce a second cache into syntax-ppss, > >>> and this cache would be used whenever (not (eq (point-min) 1)). > >>> Whenever point-min changes, and isn't 1, this second cached would be > >>> calculated again from scratch. > > Here is a patch implementing this. Comments about it would be welcome. > Thank you. It seems to hold up to the main test scenario I had in mind, > so I don't have any complaints behavior-wise. Thanks. > It looks pretty big, though. With lots of new global variables. > Before, we had syntax-ppss-cache and syntax-ppss-last. The patch adds 8 > new ones. Yes. But each one has a very single purpose, and there are no loops in the new code, which makes it easier to be sure it is correct. > I propose two avenues for simplification: > 1) Use a cons structure for the (PPSS-CACHE . PPSS-LAST) structure. We > will have three global variables total: syntax-ppss-data-wide, > syntax-ppss-data-narrow, syntax-ppss-data-narrow-point-min. syntax-ppss > would bind a local variable syntax-ppss-data to one of the first two > depending on the value of the third (and then modify its car and cdr > during the course of execution). I'm in favour rather of setting syntax-ppss-{cache,last} to the appropriate stored cache. This will avoid needing to change the function syntax-ppss much. A disadvantage of using such a cons is in debugging. It is more difficult to understand a cons like this when it is printed out, than the two component lists (which are difficult enough themselves). > 2) Some extra vars serve to delay the actual clearing of the unused > cache until it's used again. It's a valid idea, but what if we try > without it at first? So syntax-ppss-flush-cache would always clear both > caches eagerly. When there's a lot of buffer changing going on, it is an overhead having to clear both (or several) caches continually. (I'm thinking about the possible extension to using an alist of caches, which could be quite long.) Also clearing both caches at the same time would be a bigger change to syntax-ppss-flush-cache than it's suffered so far. But I'm really not sure which way is better. > The advantages: > - Less code, easier to reason about. > - Any package than advises syntax-ppss will have to juggle fewer global > variables. I was intending that the new variables be purely internal, and that no external elisp would need to access them. I suppose I really ought to have put "--" in the middle of their names. > So Vatalie's polymode will have an easier time of it. It could even > reuse some of the cache-while-narrowed logic by substituting the > values of syntax-ppss-data-narrow and > syntax-ppss-data-narrow-point-min as appropriate. That sounds a little dangerous. > The obvious downside is, of course, extra indirection, which translates > to extra overhead. We don't know how significant it will be, though. I wouldn't be keen on seeing lots of (car compound-variable) and (cdr compound-variable) throughout the syntax-ppss function. I think it would make it significantly more difficult to understand. > Would you like to see the code? Yes, why not? But just to make my position clear, I'm not particularly fixed on my patch as submitted. It was optimised for simplicity and correctness rather than elegance, though I don't think it's too bad. I'm fairly open on whether we use your suggestions or Stefan's suggestion of having an alist of caches. -- Alan Mackenzie (Nuremberg, Germany).