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:24:08 +0300 Message-ID: References: <83h8wlz1kf.fsf@gnu.org> <20170902174027.GB4267@ACM> <20170907204502.GC4488@ACM> <69e034d3-7a52-cc81-dc56-e5308ad5dce0@yandex.ru> <20170910113626.GB3588@ACM> <20170911201204.GC3605@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 1505175921 10554 195.159.176.226 (12 Sep 2017 00:25:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 12 Sep 2017 00:25:21 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: John Wiegley , Philipp Stephani , 22983@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 12 02:25:16 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 1drZ0i-0001ru-KY for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Sep 2017 02:25:04 +0200 Original-Received: from localhost ([::1]:32939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drZ0p-00014O-OS for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 20:25:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drZ0j-00013t-Tb for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:25:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drZ0f-0005vS-TD for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:25:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drZ0f-0005vM-Ox for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drZ0f-0004PN-Io for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 20:25:01 -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:25: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.150517585916879 (code B ref 22983); Tue, 12 Sep 2017 00:25:01 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 12 Sep 2017 00:24:19 +0000 Original-Received: from localhost ([127.0.0.1]:34351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drYzz-0004OB-2U for submit@debbugs.gnu.org; Mon, 11 Sep 2017 20:24:19 -0400 Original-Received: from mail-lf0-f54.google.com ([209.85.215.54]:33978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drYzx-0004Nw-3B for 22983@debbugs.gnu.org; Mon, 11 Sep 2017 20:24:17 -0400 Original-Received: by mail-lf0-f54.google.com with SMTP id l196so22449308lfl.1 for <22983@debbugs.gnu.org>; Mon, 11 Sep 2017 17:24:17 -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=/h/GGMCKbT60I7d5zLUtVSkDPGXJPYXbY4F/+Z9sN2o=; b=gTrVVdZ1h3NyMBe00LbwrIOKnh+GbN2WeeZA++scrWtb3AyTLnP0s61i23pG77DeSs gWdUKy+0CHQ8WZ7kqzaXQHsDdUVJ4LnntQmEfsfzyJvO31cDywziEpAOg8G3gZ8ZDRHH rnjU9dGoGijmsfyNdnCxtKAUczzNt9dBUr+d9Fiv1Vc1Fc4dsW9yMWbJAhjr9Lywnoak nVLGZP0rOa33EdrfT4vXgMbcVc/suCmntGwf1uVpbKXvKaT9l2q/op09U5w+bsU9lqgV KLDipcud6fqX8ccBh/o4YhKpn/Te2+AZBXipJwDSjEK1Vc0vDqOugc5yBK0PtHkkdQYC 1y1g== 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=/h/GGMCKbT60I7d5zLUtVSkDPGXJPYXbY4F/+Z9sN2o=; b=BhQFBNI2wMErL+9iMFmuBcU2/eEU48MfJdhDerHBHM5y81haVGYO7nAyiy/OaSCOE2 Zu487h0eB7JAe1f3LVvaSuVX6Ugpm5gs4V2mSavQojIzDsqZOt/R6OEjCasBieBiJiu2 Fvlu8bOgBWkavQtTOMfm4DqgU/cfId+2hXoFD9troiH62zNL/tKnD36HjCyGVUSUwVYD l+R0QL2y1D+zYC5Tx4SiA/uPOdj0luzUuYBjBU4rdzMcdzBzECkP2vMxuPjtjSYt9Ruz Vi/vgXayAvJ2pf/mlYoF3kA4L9pK3yT5B49UfN/imky6AscMi+52wqxxEKaitVnQPczD aOeg== X-Gm-Message-State: AHPjjUijWQ3hlR1MO2wSFpGBueUj/6cOhmkGaQaZgHj8LXxMb8FlLvIj qmLTWdgoUxRKFBX6NWk= X-Google-Smtp-Source: AOwi7QCf05z2QmcD6vqhK4v9e0+wbAtlT5Sjq8TppndBqYF+ZOKn2O8/C3i/gLJ7e+8R6KSDpUOlVQ== X-Received: by 10.46.0.39 with SMTP id 39mr1620735lja.13.1505175850880; Mon, 11 Sep 2017 17:24:10 -0700 (PDT) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id r80sm1447332lfi.68.2017.09.11.17.24.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 17:24:10 -0700 (PDT) In-Reply-To: <20170911201204.GC3605@ACM> 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:136820 Archived-At: On 9/11/17 11:12 PM, Alan Mackenzie wrote: >> 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. On the one hand, yes, on the other hand, the more code you have (or the more vars you have to juggle), the harder it is to keep track. > 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. My proposal will change syntax-ppss, yes. So, unfortunately, the patch will be more difficult to read. But not the resulting code, hopefully. But I think I see what you mean. The disadvantage is that we'll need code that will ferry those values back to the appropriate variables as well (which we see in your patch). We can discuss that option after. > 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). You win some, you lose some. We could use structs, if you like, but overall, the values are already complex, so consing won't make that much worse. > 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.) Both caches - yes, but shouldn't be too bad. The "alist of caches" approach would most likely require that laziness, but I'm not sure we really want to go there (see another email). > Also clearing both caches at the same time would be a bigger change to > syntax-ppss-flush-cache than it's suffered so far. True. >> - 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. Yes, but if we can make life easier for some, why not? Sometimes third-party author can life with breakage between Emacs versions. >> 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. Not much worse than what multi-mode packages already do, though. >> 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. Hopefully there will be only several such places. But again, we can use structs. >> Would you like to see the code? > > Yes, why not? Please give me until the end of the week. > 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. Cool.