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 19:42:38 +0000 Message-ID: <20170911194238.GB3605@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 1505328927 3336 195.159.176.226 (13 Sep 2017 18:55:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Sep 2017 18:55:27 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: John Wiegley , Philipp Stephani , Dmitry Gutov , 22983@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 11 21:48:19 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 1drUgm-0002Qy-7a for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 21:48:12 +0200 Original-Received: from localhost ([::1]:60181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drUgr-0002m9-Pe for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 15:48:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drUgh-0002jJ-HG for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 15:48:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drUgc-000426-Je for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 15:48:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53597) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drUgc-00041z-FA for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 15:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drUgc-00048R-3S for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 15:48:02 -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 19:48:02 +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.150515927615882 (code B ref 22983); Mon, 11 Sep 2017 19:48:02 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 11 Sep 2017 19:47:56 +0000 Original-Received: from localhost ([127.0.0.1]:34045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drUgW-000486-JX for submit@debbugs.gnu.org; Mon, 11 Sep 2017 15:47:56 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:23685 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1drUgU-00047r-Ea for 22983@debbugs.gnu.org; Mon, 11 Sep 2017 15:47:54 -0400 Original-Received: (qmail 19711 invoked by uid 3782); 11 Sep 2017 19:47:51 -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 21:47:50 +0200 Original-Received: (qmail 4910 invoked by uid 1000); 11 Sep 2017 19:42:38 -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:136922 Hello, Stefan. On Sun, Sep 10, 2017 at 18:53:53 -0400, Stefan Monnier wrote: > > +;; Several caches. > > +;; Because `syntax-ppss' is equivalent to (parse-partial-sexp > > +;; (POINT-MIN) x), we need either to empty the cache when we narrow > > +;; the buffer, which is suboptimal, or we need to use several caches. > I think that (parse-partial-sexp 1 x) is more often what the caller > wants than (parse-partial-sexp (point-min) x), but if you're happy with > the behavior described by the docstring, then that's fine. I've never been happy with the specification, partly for that reason, but we are where we are, with lots of use of syntax-ppss, so I think it needs fixing according to that spec. > > +;; The implementation which follows uses three caches, the current one > > +;; (in `syntax-ppss-cache' and `syntax-ppss-last') and two inactive > > +;; ones (in `syntax-ppss-{cache,last}-{wide,narrow}'), which store the > > +;; former state of the active cache as it was used in widened and > > +;; narrowed buffers respectively. > Earlier in the thread, I suggested to use a single cache indexed by the > position of point-min (or by the position and point-min and by the > current syntax-table, so as to also handle changes in the syntax-table), > i.e. a list of (POINT-MIN-POS . CACHE-DATA) or > ((POINT-MIN-POS . SYNTAX-TABLE) . CACHE-DATA). I think it would lead to > less code duplication than your patch which only handles 2 different > POINT-MIN-POS (and one of the two has to be equal to 1), but existing > code trumps hypothetical designs. I deliberately kept the patch simple, avoiding even an alist with the point-min position as key. This would necessitate having an arbitrary maximum length of alist, and continual manipulation of this list. Not difficult, I agree, but do we need it? How often are there going to be nested or alternating narrowing with enough calls to syntax-ppss to cause the establishment of syntax-ppss-cache (as opposed to merely syntax-ppss-last, which my patch doesn't consider sufficient reason to store a new narrow-cache)? (These aren't rhetorical questions, by the way, but real ones. Which is the best way forward?) However, the patch was deliberately contructed to make the replacement of the two-cache cache by an arbitrary length alist simple. > So, I have no objections to the patch. But I think (parse-partial-sexp > (point-min) x) is a design bug in syntax-ppss which we will need to fix > sooner or later, which is why I never bothered to implement something > like your patch, which only makes the code do what its doc says rather > than what the caller needs. I couldn't agree more. However, syntax-ppss is established and there are callers that depend on its literal specification. Maybe a way forward would be to introduce a new function equivalent to (parse-partial-sexp 1 x) and deprecate syntax-ppss. However, a name would need to be found for this new function, not an easy task. ;-) (syntax-ppss is a very good name, but couldn't be reused.) > Stefan -- Alan Mackenzie (Nuremberg, Germany).