From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result. Date: Tue, 12 Sep 2017 03:11:15 +0300 Message-ID: <922d661a-3962-4284-1a24-23c614ccdf04@yandex.ru> References: <9fc66395-045c-1984-f530-033c2ff706f6@yandex.ru> <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=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1505175160 4190 195.159.176.226 (12 Sep 2017 00:12:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 12 Sep 2017 00:12:40 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: Alan Mackenzie , Philipp Stephani , John Wiegley , 22983@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 12 02:12:35 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 1drYoF-0007zb-N4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Sep 2017 02:12:11 +0200 Original-Received: from localhost ([::1]:32903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drYoJ-0005ZZ-Jm for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 20:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drYoC-0005XR-QR for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drYo6-0000WT-Sm for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:12:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53895) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drYo6-0000WF-OV for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drYo6-00044u-Df for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Sep 2017 00:12: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.150517508615628 (code B ref 22983); Tue, 12 Sep 2017 00:12:02 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 12 Sep 2017 00:11:26 +0000 Original-Received: from localhost ([127.0.0.1]:34342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drYnV-00043z-Sj for submit@debbugs.gnu.org; Mon, 11 Sep 2017 20:11:26 -0400 Original-Received: from mail-lf0-f52.google.com ([209.85.215.52]:33160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drYnU-00043l-CU for 22983@debbugs.gnu.org; Mon, 11 Sep 2017 20:11:24 -0400 Original-Received: by mail-lf0-f52.google.com with SMTP id c80so22436223lfh.0 for <22983@debbugs.gnu.org>; Mon, 11 Sep 2017 17:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3MxNiNQqzgfjFF1cy5I/wNFz6eRe3WtzUPRvhHqgqJ8=; b=Q38F4JMwcfagiLWLimsbNF168DRspu+SU0VfYdegLug6+Rz2XfVYQPruQQqj6YTLSZ hZpysey3/GRuBIuF1acZiooYg2A60Vtk6g46ZIb0HhpMoyItf6H6FcQAGFgfZmL7zAay 9SqJHHqOR5i1T4K568QColQocmLZveuFZqd53pOZ84TGs3lE+qEYc9kSImc85vC6qjFo te8I+vkAXk+Bb+GyMMQEGMgvqHT/R+plcykIBw6RQQVOykla2VAM3Sigwx6lx6xR6zc1 ilaY72/+JnR2do3slpEITTZaevpBS5e4B4Q6ZWmP0muPps4PhywJqtrgQ75icQWKxFaJ Tq8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3MxNiNQqzgfjFF1cy5I/wNFz6eRe3WtzUPRvhHqgqJ8=; b=C9Q5d6yEHAHy2r9zqKyxP/UE+tgCRnuFsSSzULGA1jWiQifYsFWrsHKEAQs1aQkXjY cdYZKoIUkpU7gqMf+L/7KKL15ij0+utmt/ZOYvfWxUN3pwycY6yWd3I/Dj/tSyVt5vxP 0SQTni0KZeExkeap1uUAB70vFRyW5GxQlFdTR6qrtQ5v+7HykrMwGw870RiNXopTQr+j 2jT1NkKjbaCKDUzSzTI5WzyB9g99cSQocJw8JLW377vwkb5c/CtPVRIhT9oVUFgC4hek vpcU9wYkpBeVje5BQ0zTVeNLLWF5aMXeR4ZAhLyMC0J7bWIsUtIXD7cYwH8GEIdre7Bi MCBg== X-Gm-Message-State: AHPjjUhlhgIfMOorQdu8CDYPkk2COGLTsMQdafPlQGWoZ+CkW2Kfl1BY j4L66qJqOQLTcFAKRAY= X-Google-Smtp-Source: AOwi7QAnAQC7ZSi/lVqxXQpIAlje2g9nELQ81UdCBrpAEgJXHi4DBBQhe8YxBoIyD4moGk8+xPIbNA== X-Received: by 10.25.159.146 with SMTP id i140mr3763782lfe.253.1505175078253; Mon, 11 Sep 2017 17:11:18 -0700 (PDT) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id m12sm567851lje.21.2017.09.11.17.11.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 17:11:16 -0700 (PDT) In-Reply-To: Content-Language: en-US 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:136819 Archived-At: On 9/11/17 2:10 PM, Stefan Monnier wrote: > My suggestion is to have a list of N caches, instead of having exactly > 2 caches. I can't see how that could lead to more clobbering. Um, sorry I misunderstood. I interpreted that as only keeping one pair. But here are some other issues: 1) If we maintain a cache for all narrowings that have ever been used in the buffer, we adopt the idea that all of them are "real" and e.g. correspond to chunks in different major modes in a multi-mode context. Switching to a different syntax table and parsing a segment of text like ruby-syntax-propertize-percent-literal does falls outside of this concept. But of course, we can index by syntax table as well... overall, things become much complex than when changing the narrowing bounds implies just throwing away that cache. 2) If there are a lot of elements inside the cache alist, we have to get rid of them from time to time. Not sure what the rules will be. Again, if they correspond to multi-mode chunks, we can at least be confident that the number of items in the alist will be finite. Not necessarily so if narrowing+spss is used for arbitrary purposes. 3) As the number of elements in the alist grows, flushing each value inside syntax-ppss-flush-cache eagerly will become slower and slower, I expect. And a lazy strategy of the kind proposed by Alan will become necessary. >> I'm considering the idea now that syntax-ppss should stay a caching wrapper >> around parse-partial-sexp, and the responsibility to widen should always be >> the caller's. This way, it can be used for different purposes that we've >> discussed before many times. > > It does have the advantage of circumventing the discussion of > "up-to-where should we widen" ;-) Indeed. :)