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: syntax-ppss returns wrong result. Date: Thu, 7 Sep 2017 20:45:02 +0000 Message-ID: <20170907204502.GC4488@ACM> References: <20160319122759.GA2644@acm.fritz.box> <9f36a39b-ea9f-2f61-5400-68de18526ab1@yandex.ru> <9fc66395-045c-1984-f530-033c2ff706f6@yandex.ru> <83h8wlz1kf.fsf@gnu.org> <20170902174027.GB4267@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1504817446 11494 195.159.176.226 (7 Sep 2017 20:50:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 7 Sep 2017 20:50:46 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: 22983@debbugs.gnu.org, Philipp Stephani , Dmitry Gutov To: John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 07 22:50:30 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 1dq3kb-0001Yt-Sz for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Sep 2017 22:50:14 +0200 Original-Received: from localhost ([::1]:42242 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dq3kj-0008Ll-2w for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Sep 2017 16:50:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dq3kW-0008Gh-RP for bug-gnu-emacs@gnu.org; Thu, 07 Sep 2017 16:50:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dq3kR-0005Fy-No for bug-gnu-emacs@gnu.org; Thu, 07 Sep 2017 16:50:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46089) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dq3kR-0005F2-Kr for bug-gnu-emacs@gnu.org; Thu, 07 Sep 2017 16:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dq3kP-0006zD-Uw for bug-gnu-emacs@gnu.org; Thu, 07 Sep 2017 16:50: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: Thu, 07 Sep 2017 20:50: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.150481738226824 (code B ref 22983); Thu, 07 Sep 2017 20:50:01 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 7 Sep 2017 20:49:42 +0000 Original-Received: from localhost ([127.0.0.1]:54770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dq3k6-0006ya-Ey for submit@debbugs.gnu.org; Thu, 07 Sep 2017 16:49:42 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:29282 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1dq3k2-0006yQ-PK for 22983@debbugs.gnu.org; Thu, 07 Sep 2017 16:49:40 -0400 Original-Received: (qmail 24937 invoked by uid 3782); 7 Sep 2017 20:49:37 -0000 Original-Received: from acm.muc.de (p548C7C68.dip0.t-ipconnect.de [84.140.124.104]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 07 Sep 2017 22:49:36 +0200 Original-Received: (qmail 5613 invoked by uid 1000); 7 Sep 2017 20:45:02 -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:136668 Archived-At: Hello, John. On Tue, Sep 05, 2017 at 13:28:52 +0100, John Wiegley wrote: > >>>>> Dmitry Gutov writes: > > I'm sure we want to fix design flaws. As long as there is a solid plan that > > does not swap one flaw for another. > Can we have a summary of the current proposal(s) on the table? It would help > to clarify, rather than navigating past discussions. Alan has told me that > this issue is affecting people and has been outstanding for some time; I'd > like to get a better idea of its seriousness/scope, and what effect the > available solutions would have (as Dmitry says, we don't want to replace one > flaw with another). First, I think it's worthwhile emphasising what the function purports to do: syntax-ppss is a compiled Lisp function in `syntax.el'. (syntax-ppss &optional POS) Parse-Partial-Sexp State at POS, defaulting to point. The returned value is the same as that of `parse-partial-sexp' run from `point-min' to POS except that values at positions 2 and 6 in the returned list (counting from 0) cannot be relied upon. Point is at POS when this function returns. 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. This proposal has these advantages: (i) It would make the function deliver what its unchanged doc string says. This is important, given that syntax-ppss has been very widely used within Emacs, and likely by external packages too; these will typically have assumed the advertised behaviour of the function, without having tested it in narrowed buffers. (i) In the case which currently works, namely a non-narrowed buffer, there would be only a minute slow-down (basically, there would be extra code to check point-min and select the cache to use). (ii) The cache for use in a narrowed buffer might well be sufficiently fast in normal use. If it is not, it could be enhanced readily. I think Dmitry also proposed a method of solution some months ago, though I don't remember in detail what it was. Dmitry, do you still think your solution would work? If so, please elaborate on it. > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 -- Alan Mackenzie (Nuremberg, Germany).