From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#22983: syntax-ppss returns wrong result. Date: Fri, 11 Mar 2016 22:15:40 +0000 Message-ID: <20160311221540.GH2888@acm.fritz.box> References: <20160311151512.GD2888@acm.fritz.box> <20160311212410.GG2888@acm.fritz.box> <73903215-f94b-e194-7bfe-0d6350c95769@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457734463 23361 80.91.229.3 (11 Mar 2016 22:14:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2016 22:14:23 +0000 (UTC) Cc: 22983@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 11 23:14:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aeVJz-0003ll-7j for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 23:14:11 +0100 Original-Received: from localhost ([::1]:57928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeVJy-0001zB-Dj for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Mar 2016 17:14:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeVJu-0001ym-5A for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 17:14:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeVJq-0000sV-PF for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 17:14:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeVJq-0000rw-LG for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 17:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aeVJq-0000n0-9W for bug-gnu-emacs@gnu.org; Fri, 11 Mar 2016 17:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Mar 2016 22:14: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.14577343832957 (code B ref 22983); Fri, 11 Mar 2016 22:14:02 +0000 Original-Received: (at 22983) by debbugs.gnu.org; 11 Mar 2016 22:13:03 +0000 Original-Received: from localhost ([127.0.0.1]:45535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeVIs-0000ld-VS for submit@debbugs.gnu.org; Fri, 11 Mar 2016 17:13:03 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:56509) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aeVIr-0000lE-Ug for 22983@debbugs.gnu.org; Fri, 11 Mar 2016 17:13:02 -0500 Original-Received: (qmail 15964 invoked by uid 3782); 11 Mar 2016 22:13:00 -0000 Original-Received: from acm.muc.de (p579E8E6B.dip0.t-ipconnect.de [87.158.142.107]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Mar 2016 23:12:59 +0100 Original-Received: (qmail 6895 invoked by uid 1000); 11 Mar 2016 22:15:40 -0000 Content-Disposition: inline In-Reply-To: <73903215-f94b-e194-7bfe-0d6350c95769@yandex.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114794 Archived-At: Hello, Dmitry. On Fri, Mar 11, 2016 at 11:35:08PM +0200, Dmitry Gutov wrote: > On 03/11/2016 11:24 PM, Alan Mackenzie wrote: > > Er no, I meant what I wrote: the result of (syntax-ppss pos) must match > > that of (parse-partial-sexp (point-min) pos). I think ppss-0 and ppss-1 > > did actually match (but I can't quite remember). > I imagine they didn't. I got the same value in all three cases, though, > so your scenario could use some revising. Sorry about that. > >> Considering narrowing can change point-min arbitrarily, specifying > >> (syntax-ppss pos) as (parse-partial-sexp (point-min) pos) is a losing > >> proposition if you want consistency. > > Indeed. But that is how syntax-ppss is specified, and (partially) how > > it is implemented. > That part of specification can be rephrased. It's more than the specification which needs redoing. The implementation (sometimes) returns the equivalent of (parse-partial-sexp (point-min) pos)), when point-min is not in a "safe place". > >> Alas, we have some code out there that implements multiple-major-mode > >> functionality using narrowing and some hacking of syntax-ppss-last > >> syntax-ppss-cache values. > >> Changing syntax-ppss to be independent of narrowing will break it, and > >> we'll need to provide some alternative first. > > syntax-ppss is broken, and can't be fixed. > It's used ubiquitously, so it must be working. It might well be ubiquitous, but it's broken. Consider this: syntax-ppss will return the result of a parse based at point-min. In general, the caller does not know whether point-min is in a string or not. Therefore the result is of little value, UNLESS the caller takes special action, such as widening the buffer before every call to syntax-ppss. > > The only sensible fix would be to specify that (syntax-ppss pos) is > > the same as (parse-partial-sexp 1 pos). But that is then a totally > > different function, and there are around 200 uses in the Emacs > > sources to check and fix, to say nothing of external code. > Not entirely different, no. AFAIK, these are the semantics the vast > majority of its usages expect. But it's not the semantics these .el files get. What's probably keeping them functional is the rarity with which buffers are narrowed to an "awkward" point-min. > Except the multiple-major-mode case, which we'd ideally try to > accommodate, too. How does this code handle the changeover of syntax tables at a mode boundary? > >> We could introduce a syntax-ppss-dont-widen variable, though. Similar to > >> font-lock-dont-widen. > > I'm trying to figure that out. Wouldn't that still leave you with > > problems when point-min is inside a string? > syntax-ppss-dont-widen would be nil by default, it would be an escape > hatch toward the current semantics, for when the caller knows how to > manage narrowings, etc. Ah, OK. I think I see that now. Maybe. Surely the trouble is that either ALL calls or NONE must have s-p-dont-widen set. When that flag is toggled, all the caches have to be cleared. Maybe there should be some initialisation flag in some initialisation function. Or something like that. (It's getting late!). It strikes me that the multiple major mode stuff could do with a substantially enhanced version of syntax-ppss which would smoothly handle going over a mode boundary. But I don't know how you're implementing that. -- Alan Mackenzie (Nuremberg, Germany).