From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Problems with syntax-ppss: Was [... Apply `comment-depth' text properties when calling `back_comment'.] Date: Wed, 9 Mar 2016 10:49:01 +0000 Message-ID: <20160309104900.GA3948@acm.fritz.box> References: <20160308132530.861.91488@vcs.savannah.gnu.org> <20160308183010.GB6269@acm.fritz.box> <20160308200753.GC6269@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457520442 4095 80.91.229.3 (9 Mar 2016 10:47:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 10:47:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 11:47:13 2016 Return-path: Envelope-to: ged-emacs-devel@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 1adbe4-0002gw-Ea for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 11:47:12 +0100 Original-Received: from localhost ([::1]:40595 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adbe3-0008QC-NF for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 05:47:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adbdO-0007Ut-OZ for emacs-devel@gnu.org; Wed, 09 Mar 2016 05:46:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adbdK-0001sG-Kd for emacs-devel@gnu.org; Wed, 09 Mar 2016 05:46:30 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:49645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adbdK-0001s2-54 for emacs-devel@gnu.org; Wed, 09 Mar 2016 05:46:26 -0500 Original-Received: (qmail 87034 invoked by uid 3782); 9 Mar 2016 10:46:24 -0000 Original-Received: from acm.muc.de (p548A46A1.dip0.t-ipconnect.de [84.138.70.161]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Mar 2016 11:46:23 +0100 Original-Received: (qmail 8857 invoked by uid 1000); 9 Mar 2016 10:49:01 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201238 Archived-At: Hello again, Stefan. On Tue, Mar 08, 2016 at 07:17:17PM -0500, Stefan Monnier wrote: > > syntax-ppss is a lisp level thing, rather loosely defined. > No, it's pretty precisely defined: it (should) returns the same value as > (parse-partial-sexp (point-min) pos). I note the lack of confidence expressed by the word "should". Also we should surely want what the result of a scan starting at position 1 (not (point-min)) would be. > > For example it reacts to the setting/clearing of the particular > > syntax-table text properties it's sensitive to, even when > > inhibit-modification-hooks is non-nil (which it _always_ is when text > > properties are changed). > `syntax-ppss' is used all over the place, so if there's a problem with it, > we should fix it. There are several problems with syntax-ppss. It is not a rigorously correct function (which is what we would expect from this low level of the Emacs functionality.) Looking at the version in the master branch: Minor problems: (i) After inserting a `with-syntax-table' near the beginning of syntax-ppss, the indentation wasn't redone. (ii) The cache isn't flushed when a syntax-table text property gets set or cleared (see my patch for how to do this). (iii) The specification of the function states that the returned state is equivalent to a scan from (point-min) rather than 1. This parse state isn't very useful, and probably forces callers to widen before calling, or at least ensure that (point-min) isn't in a literal. Major problems: (i) The cache doesn't appear to be flushed on narrowing or widening the buffer. (ii) No account is taken of possibly starting a parse-partial-sexp from after the first character of a two character comment starter or ender. OK, this is really a problem with the parser state not recording this situation (which we could correct), but failing that, syntax-ppss should check for this. We did talk about this (in connection with a CC Mode bug) a few years ago. Also the function is complicated and difficult to understand. It seems to be fairly heavily optimised. > Stefan -- Alan Mackenzie (Nuremberg, Germany).