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: Syntax-propertize and CC-mode [Was: Further CC-mode changes] Date: Sun, 14 Sep 2014 00:04:54 -0400 Message-ID: References: <536FEA43.5090402@dancol.org> <20140516175226.GB3267@acm.acm> <537653A0.2070109@dancol.org> <20140518213331.GB2577@acm.acm> <20140912235948.GA4045@acm.acm> <20140913151055.GB3431@acm.acm> <20140913230812.GA3660@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410667522 16801 80.91.229.3 (14 Sep 2014 04:05:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 04:05:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 06:05:15 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 1XT13q-0001Sr-2x for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 06:05:14 +0200 Original-Received: from localhost ([::1]:52660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT13p-0002Nu-HA for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 00:05:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT13f-0002JF-OZ for emacs-devel@gnu.org; Sun, 14 Sep 2014 00:05:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XT13Y-0006ae-7m for emacs-devel@gnu.org; Sun, 14 Sep 2014 00:05:03 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:22651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT13Y-0006aa-4V for emacs-devel@gnu.org; Sun, 14 Sep 2014 00:04:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjiNXB4Q4BKkZgWqDTCGBLQ X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjiNXB4Q4BKkZgWqDTCGBLQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="89638882" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2014 00:04:54 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C12A563E29; Sun, 14 Sep 2014 00:04:54 -0400 (EDT) In-Reply-To: <20140913230812.GA3660@acm.acm> (Alan Mackenzie's message of "Sat, 13 Sep 2014 23:08:12 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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:174282 Archived-At: > I've separated the discussion on syntax-propertize from the rest, > because things are threatening to get out of hand. Important note: I only provided a patch to use syntax-propertize for awk-mode. This case is much simpler to handle than the C/C++/Java cases (at least, IIUC, the way you apply syntax-table properties in awk-mode is easy to map to what syntax-propertize needs). Using syntax-propertize for C/C++/Java is a whole other project, which I hope to get to at some point, but I'll need to dig much deeper into the belly of the beast before I can hope to do that. > How is the lower limit determined (matching the upper limit POS)? Syntax-propertize internally keeps track of "up-to-where have properties been applied", so that it can provide the lower limit. > At a guess, this is going to be anywhere down to BOB. That can be, tho usually it's just "the beginning of the last buffer modification". > This isn't very lazy. Why doesn't syntax-propertize take TWO > parameters, BEG and END? How would you know what is BEG without knowing what other packages (indent.el, font-lock.el, ...) have already `syntax-propertize'd? > Looking at the source, syntax-propertize is unoptimised. It will always > erase the syntax-table properties from the last buffer change onwards, in > contrast to C++ Mode, which only erases them locally as needed. syntax-propertize is lazy, but indeed it always assumes pessimistically that any change to the buffer at POS might cause everything after POS to be interpreted completely differently and hence require re-propertization. So far, this has not proved to be problematic in any of the 20 or so major modes that use syntax-propertize. > There is surely an opportunity for better customisation here. Yes, we could spice up syntax.el so that you can set some properties and explain when modifications in previous text don't invalidate them. We haven't seen a need for it so far. > That is not true. I need to know that syntax-propertize would nullify > C++/Java Modes' careful optimisations. syntax-propertize (as it stands) is probably not compatible with some of the optimizations you use, indeed. It probably gives you other optimization opportunities, of course. How well it would work is hard to tell without a lot more investigation. > I need to know whether or not syntax-propertize properly handles > category properties. By and large, `syntax-propertize' doesn't handle anything at all. It does is keep track of the BEG argument for you, and it does erase the `syntax-table' properties over BEG..END before calling syntax-propertize-function. But that's about all it does. > I suspect it doesn't. That involves reading the > source code, for lack of documentation. The source is all in a single function (called, you guessed, syntax-propertize) which weighs in at 39 lines of Elisp code, a good half of which has to do with calling syntax-propertize-extend-region-functions. > syntax-propertize needs a way of customizing its before-change function > to avoid removing ST properties needlessly from large chunks of buffer. Note that in 99% of the cases, there aren't any properties applied further in the buffer anyway, so we don't actually "needlessly" throwaway data on large chunks of buffer. That's why so far, this optimization you're suggesting has not been requested by anyone, even though modes such as (C)perl do have rather complex/costly syntax-propertize-functions and are sometimes applied to very large buffers as well. IOW, I wouldn't worry about this problem for now. We'll cross this bridge when we get there. Stefan