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: font-lock-syntactic-keywords obsolet? Date: Mon, 20 Jun 2016 09:37:04 -0400 Message-ID: References: <5764F25B.4010204@online.de> <20160618171249.GA5796@acm.fritz.box> <20160619151227.GD5875@acm.fritz.box> <20160620115726.GD3166@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1466429863 1243 80.91.229.3 (20 Jun 2016 13:37:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 13:37:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 15:37:35 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 1bEzOK-00015P-AQ for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 15:37:28 +0200 Original-Received: from localhost ([::1]:43711 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEzOE-00005i-15 for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 09:37:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEzO3-0008UE-H3 for emacs-devel@gnu.org; Mon, 20 Jun 2016 09:37:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEzO0-0000ZH-42 for emacs-devel@gnu.org; Mon, 20 Jun 2016 09:37:11 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEzNz-0000YN-TS for emacs-devel@gnu.org; Mon, 20 Jun 2016 09:37:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ClCAA731xV/0P0SC1cgxCEAoVVwxECgT08EAEBAQEBAQGBCoQjAQEDAWwGBAMFCwsNASYSFBgxiDcIzyMBAQgCIIs6hQUHhC0FnxeGXos2g1kjgWYkHIFuIoJ4AQEB X-IPAS-Result: A0ClCAA731xV/0P0SC1cgxCEAoVVwxECgT08EAEBAQEBAQGBCoQjAQEDAWwGBAMFCwsNASYSFBgxiDcIzyMBAQgCIIs6hQUHhC0FnxeGXos2g1kjgWYkHIFuIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="244716932" Original-Received: from unknown (HELO pastel.home) ([45.72.244.67]) by ironport2-out.teksavvy.com with ESMTP; 20 Jun 2016 09:37:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8CAEE64C54; Mon, 20 Jun 2016 09:37:04 -0400 (EDT) In-Reply-To: <20160620115726.GD3166@acm.fritz.box> (Alan Mackenzie's message of "Mon, 20 Jun 2016 11:57:26 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.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.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:204584 Archived-At: > 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. > You don't appear to want to take any responsibility for > getting it fixed, even though it's in "your" code. I definitely don't want to take responsibility to fix anything in particular, indeed. I hate it when a core functionality is only touched by a single individual, because it makes Emacs's development vulnerable to the disappearance of that individual. So I'd like for someone else to dig into syntax.el. > I've no expectation anything would be done about more abstract design > flaws reported as bugs. Even more abstract than bug#22983? No indeed, I'm not going to waste my time on such things. Just like you're not wasting your time trying to fix the fundamental breakage of CC-mode relying on some relations between before-change-functions, after-change-functions, and actual highlighting. As long as real concrete cases don't show up, the motivation is very low. > What I dislike about these things, as you well know, are the failings in > their fundamental design and the restrictions these place upon other > software, the way things were implemented before being thought through > properly. Believe me I did think about those things quite a bit before implementing them. > So we have bug #22983, and we have the ghastly abortion of low level > code in syntax.c calling out to high level lisp code "just to make > sure things are propertized properly". There's an example of something I've thought about a lot before implementing it. The precise implementation is probably not perfect, but the fundamental design is something I mulled over for a long time. It's far from perfect, but if we want to avoid re-scanning the whole buffer between point and point-max, we need the updates to be performed lazily, and a call to forward-sexp can't know how far ahead to do it until it's actually scanning. You made a different trade off in CC-mode, of trying hard to catch most cases where the rescan would end up not making any change. I find it is much too difficult to do such a thing in general to be worth the effort, so I preferred to try and gain speed by using laziness instead. Your trade-off also suffers from "fundamental design flaws": if syntax-propertize wasn't lazy, major modes would be forced to try and figure out when to optimize away the rescan, and if they don't try hard enough, they'd suffer from poor performance on large buffers. Stefan