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: Thu, 08 Dec 2016 16:13:04 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481231599 14676 195.159.176.226 (8 Dec 2016 21:13:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2016 21:13:19 +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 Thu Dec 08 22:13:15 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 1cF60A-0002WE-3R for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2016 22:13:14 +0100 Original-Received: from localhost ([::1]:49076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cF60C-0005lI-H9 for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2016 16:13:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cF606-0005dd-80 for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:13:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cF602-00044X-8r for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:13:10 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31321) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cF602-00044K-3F for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:13:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoIAAu3EVY/xnsSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAKUfYIIhiICghJBEgECAQEBAQEBAWIohGkBBAF5BQsLDQEmEhQYMS6ITAitFCoCixgBAQEHAiWLGYopBY98imqbGiWGFZIPJgcpeBMOI4M5HIF7IIktAQEB X-IPAS-Result: A0CoIAAu3EVY/xnsSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAKUfYIIhiICghJBEgECAQEBAQEBAWIohGkBBAF5BQsLDQEmEhQYMS6ITAitFCoCixgBAQEHAiWLGYopBY98imqbGiWGFZIPJgcpeBMOI4M5HIF7IIktAQEB X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="281983385" Original-Received: from unknown (HELO pastel.home) ([45.72.236.25]) by smtp.teksavvy.com with ESMTP; 08 Dec 2016 16:13:05 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1BBF965537; Thu, 8 Dec 2016 16:13:04 -0500 (EST) In-Reply-To: <20161208201517.GB3120@acm.fritz.box> (Alan Mackenzie's message of "Thu, 8 Dec 2016 20:15:17 +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:210157 Archived-At: >> And how would the new function not face the same breakage that can't be >> fixed? > It would have a sensible definition. "Returns the equivalent of > (parse-partial-sexp (point-min) POS)" is a silly definition which cannot > be coded up in any reasonable fashion. Oh, it can be coded alright if we want it (it's not terribly hard, actually). The choice was largely arbitrary and indeed the behavior is currently an unreliable mix of point-min and 1. Changing syntax-ppss to reliably return (parse-partial-sexp (point-min) POS) or (parse-partial-sexp 1 POS), is not terribly hard. The issue is mostly one of choosing between the two, where some cases want one and others want the other, which is why so far I haven't actually decided and left it simply unreliable when used in a narrowed buffer. >> As you should know, your comment-cache code suffers from the exact same >> problem. > Rubbish. Modulo any remaining bugs, it does what it says it does. Without your cache, the behavior of forward-comment is consistent with a semantics like (parse-partial-sexp (point-min) POS), whereas with your cache, forward-comment suddenly gets a new semantics similar to (parse-partial-sexp 1 POS). I don't claim the new behavior is worse, but it will introduce breakage in some existing code (just like my syntax-ppss patch, of course, for the same reasons). So does it "[do] what it says it does"? > 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. > Rubbish again. "Returns the equivalent of (parse-partial-sexp > (point-min) POS)" cannot be implemented in any reasonable fashion, Of course it can. Here are two easy options: - flush the cache is point-min is different from last time. - index the cache with point-min. I'm sure you too can come up with other solutions. This is a non-issue. The real issue is to decide which behavior to get when. > and just putting a `widen' into the current code won't change that > one bit. It would change the behavior to (parse-partial-sexp 1 POS) so of course, the doc would be changed accordingly. 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. > As I said above, I think syntax-ppss should be retired and replaced by a > function which does parse-partial-sexp starting at 1 rather than > (point-min). 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"? Stefan