From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Fri, 09 Dec 2016 13:47:53 -0500 Message-ID: References: <20161206195507.GA2996@acm.fritz.box> <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209180059.GB2203@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481309318 15711 195.159.176.226 (9 Dec 2016 18:48:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 18:48:38 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 09 19:48:33 2016 Return-path: Envelope-to: ged-emacs-devel@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 1cFQDg-0003B7-Oe for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 19:48:33 +0100 Original-Received: from localhost ([::1]:48272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFQDk-0000QP-Ta for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 13:48:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFQDA-0000KQ-5V for emacs-devel@gnu.org; Fri, 09 Dec 2016 13:48:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFQD6-000239-8P for emacs-devel@gnu.org; Fri, 09 Dec 2016 13:48:00 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:8144) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cFQD6-00022l-0c for emacs-devel@gnu.org; Fri, 09 Dec 2016 13:47:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BuEQAu3EVY/xnsSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUhHiXCiYBlFaCCIYcBAICghFAFAECAQEBAQEBAWIohGkBBAFWIwULCw4mEhQYDSSIegipcIMki0QBAQEHAiWLGYopBY98imqbGoY6kg8fN3gTDiOFUCCJLQEBAQ X-IPAS-Result: A0BuEQAu3EVY/xnsSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUhHiXCiYBlFaCCIYcBAICghFAFAECAQEBAQEBAWIohGkBBAFWIwULCw4mEhQYDSSIegipcIMki0QBAQEHAiWLGYopBY98imqbGoY6kg8fN3gTDiOFUCCJLQEBAQ X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="282112000" Original-Received: from 45-72-236-25.cpe.teksavvy.com (HELO pastel.home) ([45.72.236.25]) by smtp.teksavvy.com with ESMTP; 09 Dec 2016 13:47:53 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 909C66554A; Fri, 9 Dec 2016 13:47:53 -0500 (EST) In-Reply-To: <20161209180059.GB2203@acm.fritz.box> (Alan Mackenzie's message of "Fri, 9 Dec 2016 18:00:59 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210199 Archived-At: >> > Nor should it. Our primitives `car', `cdr', `list', etc. also don't say >> > what the intention behind them is; they just work. Narrowing is what it >> > is. Simple and austere. Complexifying narrowing by introducing a >> > notion of "intention" would surely make it more difficult to use and >> > possibly foul things up massively. >> Yet, you want to use (parse-partial-sexp 1 POS), which only makes sense >> if you treat narrowing as having a particular intention. > No. It makes sense, full stop. If it doesn't, then the notion of > narrowing doesn't make sense either. What is your understanding of "narrowing"? In my book, what it means is "make the text outside of the region inaccessible". So why should syntax-ppss be granted an exception (note: I don't disagree that it can make sense to grant an exception for it, but that granting it an exception only makes sense based on some expected usage context of narrowing, i.e. based on the intention behind its use). > There is nothing in the notion of narrowing which suggests that it > should change the syntactic context of any text - if a certain buffer > position is inside a string, it is inside the string; it doesn't > suddenly become outside the string by virtue of where the buffer is > narrowed. Were that not the case, the notion "inside a string" would > become meaningless. Let's take sm-c-mode as an example: it marks CPP preprocessor elements as being comments. Yet, it also wants to know if there are strings inside that "comment", so it narrows to the "comment" and then parses the result as a chunk of C code. [ Whether this approach is good or bad is beside the point: this is just an example of narrowing, where the context should not affect what is considered "inside a string" or not. ] Other examples come from the context of multiple-major-modes-in-a-buffer. Yet others come from the use of narrowing in things like Info-mode and Rmail (where a large buffer contains many "pages" and that's an implementation detail: the user only cares about the pages and not whether they're kept in a single buffer/file or not). >> Of course it can. Here are two easy options: >> - flush the cache if point-min is different from last time. > Likely, the cache would be flushed so much it wouldn't really serve much > purpose. Could be. Then again, maybe not. After all, you're saying that the only "meaningful" use is when the scan starts at 1, so the overwhelming majority of uses should be in a widened buffer (or are errors that need to be fixed). Only experimentation could say that. But FWIW, my gut feeling agrees with yours. >> - index the cache with point-min. > I don't understand what you mean by this. The cache is currently (conceptually) a function which takes a buffer position and returns to you an earlier position, along with the state at that position. Change this so that the function takes additionally `point-min` as argument, so it can keep different states for the same positions, depending on the `point-min` that was used to compute that state. Or more concretely, replace `syntax-ppss-cache` with (assq (point-min) syntax-ppss-cache-alist). >> Currently any code which relies on syntax-ppss returning >> (parse-partial-sexp (point-min) POS) when narrowed is broken anyway, >> so we can easily make such a change. > No, that code is not broken. Together with the existing implementation of syntax-ppss, it's very unlikely to work reliably. > It is syntax-ppss that is broken. If you replace syntax-ppss with > a different function (as I have been advocating), that is going to > break some code which uses syntax-ppss. I think that any such breakage could be reproduced with the current implementation of syntax-ppss, which would mean that the problem is not a new problem introduced by the "different" function. >> We're talking about changing 3 lines of doc and 2 lines of code. >> Why would you describe such a trivial change as "retire and replace"? > Because we're talking about a different function which does a job > different from what syntax-ppss is specified to do. That is not a minor > change, regardless of how few lines of code and documentation need to be > changed. I consider the behavior of syntax-ppss when point-min!=1 to be currently undefined (and indeed, it's unreliable). So what we're discussing is how to refine/augment/improve the behavior, rather than introducing a brand new behavior. Stefan