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: Sat, 18 Jun 2016 17:12:49 +0000 Message-ID: <20160618171249.GA5796@acm.fritz.box> References: <57627D13.5090008@online.de> <5764F25B.4010204@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 1466269986 10223 80.91.229.3 (18 Jun 2016 17:13:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jun 2016 17:13:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 18 19:12:57 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 1bEJnj-0007Bv-D9 for ged-emacs-devel@m.gmane.org; Sat, 18 Jun 2016 19:12:55 +0200 Original-Received: from localhost ([::1]:35664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEJnf-0003kb-2q for ged-emacs-devel@m.gmane.org; Sat, 18 Jun 2016 13:12:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEJnZ-0003kV-9j for emacs-devel@gnu.org; Sat, 18 Jun 2016 13:12:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEJnT-0001Bj-6z for emacs-devel@gnu.org; Sat, 18 Jun 2016 13:12:44 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:24494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEJnS-0001BO-Rz for emacs-devel@gnu.org; Sat, 18 Jun 2016 13:12:39 -0400 Original-Received: (qmail 33906 invoked by uid 3782); 18 Jun 2016 17:12:37 -0000 Original-Received: from acm.muc.de (p548C67AF.dip0.t-ipconnect.de [84.140.103.175]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 18 Jun 2016 19:12:35 +0200 Original-Received: (qmail 5936 invoked by uid 1000); 18 Jun 2016 17:12:49 -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:204474 Archived-At: Hello, Noam. On Sat, Jun 18, 2016 at 11:07:03AM -0400, Noam Postavsky wrote: > On Sat, Jun 18, 2016 at 3:03 AM, Andreas Röhler > wrote: > > Anyone who looks how syntax-propertize-function is introduced in source, > > --given some decent understanding of Emacs Lisp-- will see the bunch of > > issues. There is nothing to explain here. > Ah, is this like The Emperor's New Clothes? Anyone who doesn't see the > issues lacks a decent understand of Emacs Lisp? I'll play the kid who > doesn't know any better. Here's the source where > syntax-propertize-function is introduced: I see the issues here, and I avoid syntax-propertize and syntax-ppss wherever possible. > ;;; Applying syntax-table properties where needed. > (defvar syntax-propertize-function nil > ;; Rather than a -functions hook, this is a -function because it's easier > ;; to do a single scan than several scans: with multiple scans, > [more commentary explaining issues with multiple scans that have been > avoided...] > Looks like a normal defvar to me. Let's have that excerpt in full: ;; Rather than a -functions hook, this is a -function because it's easier ;; to do a single scan than several scans: with multiple scans, one cannot ;; assume that the text before point has been propertized, so syntax-ppss ;; gives unreliable results (and stores them in its cache to boot, so we'd ;; have to flush that cache between each function, and we couldn't use ;; syntax-ppss-flush-cache since that would not only flush the cache but also ;; reset syntax-propertize--done which should not be done in this case). The issue is not caused by multiple scans. CC Mode (in particular C++ Mode) does several scans to apply syntax-table text properties, simply because that's a natural thing to do (there being several distinct reasons for these properties being applied). That way, it's easier to debug, easier to understand, and less error prone. It is not "easier to do a single scan". It is simply that a single scan is virtually forced if one uses the syntax-ppss/syntax-propertize mechanism, because: (i) parse-partial-sexp is very likely to be needed for calculating the syntax-table text properties. Because only some s-t properties will have been applied, precise control of p-p-s is needed. I think users of syntax-ppss hold that using parse-partial-sexp directly is a Bad Thing. (ii) The only way syntax-propertize gets called is by calling syntax-ppss for some position below where one needs the properties applying. Additionally, syntax-ppss hasn't conformed with its specification w.r.t. narrowed buffers for a long time, if ever. (See bug #22983.) Additionally 2, when syntax-propertize-function is non-nil, all syntax-table text properties beyond point are wiped out by a change, causing the need to regenerate them. This is not always necessary, and might be expensive in run time (see, again, C++ Mode). In summary, the syntax-ppss/syntax-propertize mechanism might be a good choice for implementing syntax-table text properties, but it is not necessarily so. -- Alan Mackenzie (Nuremberg, Germany).