From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Wedler, Christoph" Newsgroups: gmane.emacs.devel Subject: RE: Clarification needed: syntax-propertize vs font-lock-syntax-table Date: Mon, 23 Nov 2015 17:05:20 +0000 Message-ID: References: <564CC55B.4060102@yandex.ru> <564F68C4.1020207@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448298363 16316 80.91.229.3 (23 Nov 2015 17:06:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2015 17:06:03 +0000 (UTC) To: Dmitry Gutov , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 18:05:58 2015 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 1a0uYu-0003lQ-Bz for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2015 18:05:56 +0100 Original-Received: from localhost ([::1]:33620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0uYu-0004UW-Tg for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2015 12:05:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0uYS-0004Pr-3l for emacs-devel@gnu.org; Mon, 23 Nov 2015 12:05:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0uYN-00074I-Qn for emacs-devel@gnu.org; Mon, 23 Nov 2015 12:05:28 -0500 Original-Received: from smtpgw02.sap-ag.de ([155.56.66.97]:49248 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0uYN-000741-Hs for emacs-devel@gnu.org; Mon, 23 Nov 2015 12:05:23 -0500 Thread-Topic: Clarification needed: syntax-propertize vs font-lock-syntax-table Thread-Index: AQHRIjAlZfv0vIqNQrCiB+oo5A0cI56lQRZFgASQCSA= In-Reply-To: <564F68C4.1020207@yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.114] X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 X-Received-From: 155.56.66.97 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:195122 Archived-At: >> And syntax-propertize should be called at more places. Currently, doing >> it lazily does not really work, as it is not called when needed. > You'll have to be more specific. Well, I realized that (with Emacs-24.4) the imenu list in antlr-mode wasn't correctly before I put (syntax-propertize (point-max)) into antlr-imenu-create-index-function. I could imagine similar things in other modes. I have not seen other issues, but I do use font-lock (which also calls syntax-propertize), as it is the default. I could imagine that issues could appear for people who have switched off font-lock. (Needs to be tested.) >> That is why js-mode calls (syntax-propertize (point-max)) at the end >> > Y Not anymore, it doesn't. You are right... >> (and I will do the same in antlr-mode). > I'd prefer if you didn't. I probably define a variable for that which will be t for Emacs below emacs-25.x and nil with the next release. >> My other question was concerning (nth 9 ppss), i.e. the list of open >> parentheses is very useful to have (and its also used in syntax.el >> itself) -> I would like to have this to be official in the lisp >> docstring as well - in src/syntax.c, we have > I thought that's exactly what you meant by documenting the 9th element.=20 > Were there any other options? The other documentation request was for font-lock syntax-table as being "syntax-ppss-compatible" (as you put it nicely). > I'm not the guy who can say if it's okay or not. Probably is. But it=20 > would be sad if after that we choose a way to adapt syntax-ppss for the=20 > multiple-modes case, and it will require saving a more complex structure= =20 > in the 9th element. Agreed. How about a function like (defun syntax-ppss-open-list-positions (ppss) "Get all syntactically open list position found in a syntactic scan. PPSS is a scan state, as returned by `parse-partial-sexp' or `syntax-ppss'. The start position of the outermost list comes first." (nth 9 ppss)) This function needs to be changed if the internal structure of (nth 9 ppss) is changed. >> In the case of antlr-mode (grammar with actions), it could be done as >> long as it does not break the calulation of the "inner-mode-chunk-end", >> e.g, with Python actions >> >> rule: "KEYWORD" { do_something { } # do it }; >> >> the action ends with the final "}" (even though a naive Python-like >> syntax-propertization would think of it as part of a comment) > Yes, of course we should try to make it break as few things as possible.= =20 > Not sure if I could comment on this in any more detail. We might need something (an extra syntax flag?) which makes it easy to "rewind" the ppss such that (equal (syntax-ppss inner-mode-end-position) (syntax-ppss inner-mode-start-position))