From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Tue, 11 Feb 2014 20:30:22 -0500 Message-ID: References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392168636 11792 80.91.229.3 (12 Feb 2014 01:30:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2014 01:30:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 12 02:30:42 2014 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 1WDOew-0004Ny-8r for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 02:30:42 +0100 Original-Received: from localhost ([::1]:36827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDOev-0008HZ-Io for ged-emacs-devel@m.gmane.org; Tue, 11 Feb 2014 20:30:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDOem-0008HU-0H for emacs-devel@gnu.org; Tue, 11 Feb 2014 20:30:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDOed-0001MS-Sx for emacs-devel@gnu.org; Tue, 11 Feb 2014 20:30:31 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDOed-0001MO-MU for emacs-devel@gnu.org; Tue, 11 Feb 2014 20:30:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpaAU/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgaxH5AOkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFFpaAU/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgaxH5AOkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47365288" Original-Received: from 69-165-160-20.dsl.teksavvy.com (HELO pastel.home) ([69.165.160.20]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Feb 2014 20:30:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9E935602E2; Tue, 11 Feb 2014 20:30:22 -0500 (EST) In-Reply-To: <52F96284.50507@yandex.ru> (Dmitry Gutov's message of "Tue, 11 Feb 2014 01:36:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169538 Archived-At: >> IIRC the reason was so that (syntax-ppss) called from a place like >> a "column-0 just before an open paren" can correctly indicate if this >> open paren is within a string/comment while at the same time parsing the >> subsequent text assuming that this open paren was outside of any >> string/comment. > Why? That sounds confusing. That's the point: it makes it possible to find those sources of confusion and highlight them. E.g. I had some font-lock code which would highlight an open-paren-in-column-0-in-string/comment with the `warning' face. So such an "incorrect" open paren would still cause incorrect highlighting, but the `warning' face on it would provide the clue as to what was the source of the problem. > I would've bound `syntax-ppss-last` and `syntax-ppss-cache` to nil around > the region and let it be forced to call the syntax-begin-function. Right, but that largely defeats the purpose of syntax-ppss (which is to use caching to speed up (parse-partial-sexp (point-min) (point))). To give you some background: I think syntax-begin-function is basically useless. It's used in very few places (it used to be used in lisp-mode, but that was disabled recently, it's still used in js-mode, but it should probably be disabled there as well, and apparently mmm-mode also uses it, but these are the only cases I know) and is more trouble than it's worth. It was meant and is designed as an optimization, but it is vanishingly often useful. For your use case, you don't want to provide an optimization. We should instead provide a new hook whose use would be mandatory (i.e. which syntax.el has to obey). I'm not completely sure what it could/should look like, tho. One option is to have a hook that takes a (POS . PPSS) pair, which syntax-ppss intends to use as a starting point for parsing, and return a new such pair to use instead, where the returned position should always be >= POS. This way, syntax-ppss could make full use of its cache, but mmm-mode could tell it about chunk boundaries (and decide what state to use at the beginning of a boundary). The main problem I see with this approach is that this hook would be called maybe too many times, so we'd want to improve the "fast path" (i.e. the first branch in syntax-ppss which tries to use syntax-ppss-last) so it can know when calling this new hook is unneeded. Maybe for that, the new hook should return not just a new (POS . PPSS) but also a "next-boundary" so we know we don't need to call this hook again as long as we're within POS...NEXT-BOUNDARY. Stefan