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: font-lock-syntactic-keywords obsolet? Date: Mon, 20 Jun 2016 18:55:13 +0000 Message-ID: <20160620185513.GD2192@acm.fritz.box> References: <20160619151227.GD5875@acm.fritz.box> <20160620115726.GD3166@acm.fritz.box> <34a11f84-c6c8-0fb2-f289-e4cadf83193c@online.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1466448958 25751 80.91.229.3 (20 Jun 2016 18:55:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 18:55:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andreas =?iso-8859-1?Q?R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 20:55:49 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 1bF4ML-00075d-Mf for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 20:55:45 +0200 Original-Received: from localhost ([::1]:45742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF4MK-0002kM-Qt for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 14:55:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF4Li-0002b7-2w for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:55:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF4Lf-0002iy-01 for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:55:06 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:12304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF4Le-0002iY-MK for emacs-devel@gnu.org; Mon, 20 Jun 2016 14:55:02 -0400 Original-Received: (qmail 14944 invoked by uid 3782); 20 Jun 2016 18:55:00 -0000 Original-Received: from acm.muc.de (p548C7218.dip0.t-ipconnect.de [84.140.114.24]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 20 Jun 2016 20:54:59 +0200 Original-Received: (qmail 12827 invoked by uid 1000); 20 Jun 2016 18:55:13 -0000 Content-Disposition: inline In-Reply-To: <34a11f84-c6c8-0fb2-f289-e4cadf83193c@online.de> 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:204605 Archived-At: Hello, Andreas. On Mon, Jun 20, 2016 at 06:00:01PM +0200, Andreas Röhler wrote: > On 20.06.2016 15:50, Dmitry Gutov wrote: > > On 06/20/2016 04:37 PM, Stefan Monnier wrote: > >>> I've tried doing this with an actual bug, namely bug #22983 > >>> "syntax-ppss > >>> returns wrong result". That was over three months ago, and still there > >>> is no fix. > >> Indeed, no fix. A few reasons: > >> - Lack of a concrete case which suffers from it (not much immediate > >> benefit). > >> - In many cases, it's easier to fix the other side (the caller of > >> syntax-ppss). > >> - It's hard to fix it right, not because of syntax-ppss in particular, > >> but because it's hard to make a generic facility which can be fast by > >> using a cache, yet is not being told where is the real intended > >> beginning of the buffer. In CC-mode you just decided to punt and > >> disallow the use of cc-mode where 1 is not the real beginning of the > >> C code. So your approach suffers from the same problem (just the > >> other side of it) and you haven't fixed it either. > >> This said, a quick&dirty fix (if such was needed, e.g. because of a > >> concrete > >> case which exhibits the problem) would be to make syntax-ppss > >> always widen (and maybe add a syntax-ppss-dont-widen). Given that > >> there's no real hurry to fix it, I'd rather we fix it right. > > I'm very tempted to fix it by pushing the proposed patch into master, > > considering no viable alternative patch has been proposed so far, if > > only to avoid seeing Alan mention that bug for the 101th time > IMHO syntax-ppss has many design issues, not a single one. I agree wholeheartedly. > I'd prever to see an example, where syntax-ppss can't be replaced by > parse-partial-sexp. Well, syntax-ppss was originally intended to give the result equivalent to (parse-partial-sexp (point-min) pos), and probably does, providing the buffer is never narrowed - with narrowing, you get a somewhat random result. > From there designing a syntax-ppss capable of its tasks might be of > interest. One of the problems is that syntax-ppss, rather than just performing its function, has the subsidiary function of applying syntax-table text properties. Eliminating this incoherence would be a good design aim. In fact, finding a good way of applying the text properties would win you a medal, in my eyes. -- Alan Mackenzie (Nuremberg, Germany).