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: Tue, 24 Nov 2015 08:58:13 +0000 Message-ID: References: <564CC55B.4060102@yandex.ru> <564F68C4.1020207@yandex.ru> <56536294.1000302@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 1448355511 20340 80.91.229.3 (24 Nov 2015 08:58:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2015 08:58:31 +0000 (UTC) To: Dmitry Gutov , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 24 09:58:30 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 1a19Qi-0002We-HN for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2015 09:58:28 +0100 Original-Received: from localhost ([::1]:37015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a19Qj-0005iT-LF for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2015 03:58:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a19Qc-0005eQ-PS for emacs-devel@gnu.org; Tue, 24 Nov 2015 03:58:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a19QX-0000EX-Mc for emacs-devel@gnu.org; Tue, 24 Nov 2015 03:58:22 -0500 Original-Received: from smtpgw03.sap-ag.de ([155.56.66.98]:10222 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a19QX-0000D3-AA for emacs-devel@gnu.org; Tue, 24 Nov 2015 03:58:17 -0500 Thread-Topic: Clarification needed: syntax-propertize vs font-lock-syntax-table Thread-Index: AQHRIjAlZfv0vIqNQrCiB+oo5A0cI56lQRZFgAS9VdiAAOlbEA== In-Reply-To: <56536294.1000302@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.98 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:195160 Archived-At: > Note that calling (syntax-propertize (point-max)), as js-mode was doing,= =20 > is not a guarantee of the file staying entirely up-to-date WRT syntax=20 > properties as the user edits it. I now checked the code: it is done via jit-lock-after-change in after-change-functions. As I have guessed, syntax-propertize currently only works correctly if font-lock is switched on. > Neither is using font-lock: we fontify the file lazily, and thus also=20 > only propertize the buffer near its visible part. Yes, but navigation command like M-x forward-list do not depend on font-lock, but they do depend on syntax-propertize (consider parentheses in generic strings). > But nothing has changed in Emacs 25 in that regard (I think?). We=20 > changed js-mode behavior, but mostly because it was a kludge anyway, and= =20 > not because anything else is compensating for it now. Well, then I think that the change in js is wrong. (Yes, a fully lazy solution is better, but as long as it is not there...) >> The other documentation request was for font-lock syntax-table as being >> "syntax-ppss-compatible" (as you put it nicely). > I'd be happy to review the documentation patch. We can also ask Stefan=20 > to do that. OK, I send a suggestion later this week, together with: >> 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-pps= s'. >> 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. > Yes, that sounds good (maybe choose a shorter name?). But see above. Ok, I'll name it syntax-ppss-open-positions (like (nth 0 ppss) is called syntax-ppss-depth, and not syntax-ppss-list-depth). >> 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)) > That sounds like it might require turning the current "list of openers"=20 > structure into a list-of-lists, where each element is the current "list=20 > of openers", plus some boundary information. > Or maybe handle that in some entirely different way, like keeping the=20 > current spss format, but allow the buffers to override the syntax-ppss=20 > logic via a newly introduced syntax-ppss-function variable. Well, that was the point of the above function: in the former case, the function body is changed to (mapcar 'car (nth 9 ppss)), and will stay the same in the latter.