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: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please. Date: Sat, 11 Jun 2016 21:44:27 +0000 Message-ID: <20160611214427.GG2776@acm.fritz.box> References: <20160607220928.GA5155@acm.fritz.box> <20160611102419.GC2776@acm.fritz.box> <537229d1-1737-9774-1dae-77bcee915de3@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1465681480 16799 80.91.229.3 (11 Jun 2016 21:44:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2016 21:44:40 +0000 (UTC) Cc: emacs-devel@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 11 23:44:31 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 1bBqhi-0004Ow-AP for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 23:44:30 +0200 Original-Received: from localhost ([::1]:48762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBqhh-0003Hk-8G for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 17:44:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBqhZ-0003GQ-Cm for emacs-devel@gnu.org; Sat, 11 Jun 2016 17:44:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBqhW-0001eu-9d for emacs-devel@gnu.org; Sat, 11 Jun 2016 17:44:21 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:27361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBqhW-0001em-3B for emacs-devel@gnu.org; Sat, 11 Jun 2016 17:44:18 -0400 Original-Received: (qmail 64425 invoked by uid 3782); 11 Jun 2016 21:44:16 -0000 Original-Received: from acm.muc.de (p548C7AF3.dip0.t-ipconnect.de [84.140.122.243]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Jun 2016 23:44:14 +0200 Original-Received: (qmail 31468 invoked by uid 1000); 11 Jun 2016 21:44:27 -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.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:204294 Archived-At: Hello, Stefan and Dmitry. On Sat, Jun 11, 2016 at 05:24:25PM -0400, Stefan Monnier wrote: > > If we follow this path, and not hard-widen, the proposal must carefully > > consider the existing use cases for font-lock-dont-widen. Because if Er, hang on a moment, you two! The thread is supposed to be about syntax-ppss. syntax-ppss is supposed to be a function which does one thing and does it well. That one thing is to determine, possibly from a cache, the equivalent to (parse-partial-sexp "1" pos) , where "1" may take non-canonical values. Use cases for font-lock-dont-widen, existing or not, HAVE NO BEARING on that determination of the parse-partial-sexp equivalent. So why are we talking about them here? > Yes, the new mechanism should really supercede font-lock-dont-widen. > Just syntax-ppss-base as a single integer probably wouldn't cut it. > It should probably be a setting that's not specifically tied to > `syntax'. How can anything more than a single integer be required to specify the desired value of "1"? > And as you point out in another message, it might make sense to have it > specify an upper-bound too. Maybe, but that's got nothing to do with syntax-ppss. Can we PLEASE not confuse the specification and inner workings of syntax-ppss with the contexts in which it may or may not be used? I propose one third of us should now fix syntax-ppss so that it conforms to its (new) specification, and that syntax-ppss-base should comprise an integral part of this fix. I don't consider myself to be the best of the three of us for this job (given that I dislike syntax-ppss) but I'll do it if nobody else is willing to. > Stefan -- Alan Mackenzie (Nuremberg, Germany).