From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas =?UTF-8?Q?R=C3=B6hler?= Newsgroups: gmane.emacs.bugs Subject: bug#22983: syntax-ppss returns wrong result. Date: Fri, 8 Sep 2017 18:04:37 +0200 Message-ID: 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> <20170907204502.GC4488@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AEAAB077A7F25D0F7080D27A" X-Trace: blaine.gmane.org 1504885796 988 195.159.176.226 (8 Sep 2017 15:49:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 8 Sep 2017 15:49:56 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Cc: Alan Mackenzie , John Wiegley To: 22983@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 08 17:49:49 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 1dqLXK-0007vT-D9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Sep 2017 17:49:42 +0200 Original-Received: from localhost ([::1]:46040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqLXP-0003et-GA for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Sep 2017 11:49:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqLWm-0003Ns-Bv for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:49:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqLWi-0008OP-Bq for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:49:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47487) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqLWi-0008OK-8x for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:49:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dqLWg-0005Yw-B4 for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:49:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Sep 2017 15:49: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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.150488572721361 (code B ref -1); Fri, 08 Sep 2017 15:49:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Sep 2017 15:48:47 +0000 Original-Received: from localhost ([127.0.0.1]:56168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqLWQ-0005YS-U5 for submit@debbugs.gnu.org; Fri, 08 Sep 2017 11:48:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqLWK-0005Y5-1Y for submit@debbugs.gnu.org; Fri, 08 Sep 2017 11:48:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqLWD-00085P-BY for submit@debbugs.gnu.org; Fri, 08 Sep 2017 11:48:34 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:45694) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dqLWD-00085G-7b for submit@debbugs.gnu.org; Fri, 08 Sep 2017 11:48:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqLWB-00036Y-Eu for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:48:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqLW7-000828-Ga for bug-gnu-emacs@gnu.org; Fri, 08 Sep 2017 11:48:31 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.131]:61976) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqLW7-000816-4y; Fri, 08 Sep 2017 11:48:27 -0400 Original-Received: from [192.168.178.35] ([77.12.83.176]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.167]) with ESMTPSA (Nemesis) id 0LwEHK-1dOAdG0KuU-0183XU; Fri, 08 Sep 2017 17:48:20 +0200 In-Reply-To: <20170907204502.GC4488@ACM> Content-Language: en-US X-Provags-ID: V03:K0:ThBgHvYZFd+BKg+YdTMOa/ekM8HuM2W8G8+lnRGFuquRZ5S1E/S kGOmBssS6CfbuYJpkqm6829ebuCoY5yq4d0G81s5dbL6i8aoqzDXVcx9S89sDI0nir+wAg4 R4tVMIv3/PAXbhobSQCBeEEBmMd6cpMK/VgMSJeXhyewwLdcJ3l6nO6/6CZCp8lK2FD9SNk Lfn3nvza49XQLWiuOPpZw== X-UI-Out-Filterresults: notjunk:1;V01:K0:DEPO6jU5its=:oz36LRMFssTA/JaQQVmnmn 7vDMDlkmsUGR093S1z1s20nVY4g5suIpwWF+/hg7tLyvthuo1czRXjk5ZfQu/GFgykNxCm2Px bRSIK1BbHEsbYyqIgwOXILnsNaLZGqu0XxoeoaDKOgvUdY4uG2IgeOrBSc3U+nLRDIecWShLh hm8D4u3XkKAUCSvJQFRHi9QxXCWLmfLWy+9VjkQoWDsnt1Rvn9aNJvBnTKj5ryyd8STm99nLu rAaYp2aqF1k1exPV2MyM/vLPDuTcu9W5/pBq44wwa1GlffGih2jpw9tJvQs1Pge8RbP5w8Q72 PpVGjdKLVDfzimHLcjDVjWlcBgoJifz1nap3GOFZMa7Fzz1TkQhHUJz3u++yayNcu1gGekmqU VfuYHFRGhmWkph+V7Ub3Sng9afKPJWoDMTc9c+8tCsqxnCYKTBHtQz5szFZK+zF/8bExC5ZTM 3y4QaJ7dDV5u6nsH0LrIDUmYn3wUp+Apv/K03r1mDSc7snd7vXrBInnzLmzXyGPHKh0Icf67F w/rlklx2BAKR3/Yac8O798paGZKsUkVSPSUf6yOW1PcUK3AMnT8NKAAIp18ZMd0nQhbMPCFuR ZnqlOyHBOZmSgH8IDUciA0Hm5nhQMlxCgHW+K1i9LGqxAmzKBxCOQfGGcyvO7mz8QYMnGorlo egnSlzfG+8aCsqNN2JkWkurxjLgbqjAW/4QQfAfXKQGiJOpPYKvASk5eKJJBbgPc7flWv7C/0 tLVPuy1q87tNpHeK6P/UGjyqjbuy7+KgbRYPHeit7KERJaOLXyVXxbR+rMs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:136685 Archived-At: This is a multi-part message in MIME format. --------------AEAAB077A7F25D0F7080D27A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 07.09.2017 22:45, Alan Mackenzie wrote: > 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 Hi Alan and all, assume a complex matter behind, a bunch of bugs resp. design issues, not a single one. Fixing this would affect syntax-propertize, parse-partial-sexp, syntax-ppss and font-lock stuff at once. http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html points at some spot. There should be more. As a first step listing referential tests including benchmarks should be helpful. --------------AEAAB077A7F25D0F7080D27A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 07.09.2017 22:45, Alan Mackenzie wrote:
Hello, John.

On Tue, Sep 05, 2017 at 13:28:52 +0100, John Wiegley wrote:

Dmitry Gutov <dgutov@yandex.ru> 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


      

      

    

    

    Hi Alan and all,

    

    assume a complex matter behind, a bunch of bugs resp.
      design issues, not a single one.

    Fixing this would affect syntax-propertize,
      parse-partial-sexp, syntax-ppss and font-lock stuff at
      once.

    

    http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html

    points at some spot. There should be more. 

    

    As a first step listing referential tests including
      benchmarks should be helpful.

    

    

    

  


--------------AEAAB077A7F25D0F7080D27A--