From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords obsolet? Date: Sun, 19 Jun 2016 20:55:52 +0300 Message-ID: <751427e7-f305-7790-99f5-dea230d8e6c4@yandex.ru> References: <20160618171249.GA5796@acm.fritz.box> <20160619133143.GA5875@acm.fritz.box> <20160619145934.GC5875@acm.fritz.box> <6bc7b3bc-ddb7-c041-9f68-f8b5faeca63b@yandex.ru> <20160619151836.GE5875@acm.fritz.box> <1d4c62e6-905b-4a51-28b8-e68169fb3269@yandex.ru> <20160619153455.GG5875@acm.fritz.box> <11c988f0-94c0-40dd-b9cd-5a5e27028b63@yandex.ru> <20160619171531.GH5875@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466358969 8833 80.91.229.3 (19 Jun 2016 17:56:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jun 2016 17:56:09 +0000 (UTC) Cc: emacs-devel@gnu.org, Noam Postavsky To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 19 19:56:09 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 1bEgx6-0002ud-Mj for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 19:56:08 +0200 Original-Received: from localhost ([::1]:39606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEgx5-00023A-N4 for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 13:56:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEgwz-00022t-Gs for emacs-devel@gnu.org; Sun, 19 Jun 2016 13:56:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEgwu-0001LQ-I6 for emacs-devel@gnu.org; Sun, 19 Jun 2016 13:56:01 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEgwu-0001LL-7s for emacs-devel@gnu.org; Sun, 19 Jun 2016 13:55:56 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id v199so43666850wmv.0 for ; Sun, 19 Jun 2016 10:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YE1msqwpvn2F2hD6MDi3v6MIQ2Nero+plekOImSXfUs=; b=qGORJvm2F6Bri+c3RsJEnaY5AS9a0G1fcBittLV7Tt/kNVh8+vsm5T9QljJhhVpijj Dj8T2WfM2MnWQqkG+q7OZ6Q/wMXTd9MFExIzD3YjViWKS6kCCU1XXxAW8/5YpqPc1MAA P8L+VNz/cMvKVwaaxkOoEu69H+AZ3FFQzk9VNf76A+525v64gKCCtJYLOiZLZNwFHIP6 W65akAu0p+gflUUOVmWsq6ZAq1pyKHqY/rJvWotKnj325rj5G8REVYAcf4cxcWUAx8bo NEACL+wy8bkTwxVoKtHJlVRcZYrq8U4vZISUBuUdv4/u2kUAATYzKf39aZATT4AAyD1M khCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YE1msqwpvn2F2hD6MDi3v6MIQ2Nero+plekOImSXfUs=; b=MACItXDSPqqnaafOXE/auPAnbk35P/Dz93/3itDH9/z5fz3Xyo3ft5zqKqa+hsuwA3 YBNCLF3uwh//9fPYxzsWQv4SUgR3uDyuAwB4zzLr2RY+Pb37EV6xVmktqC6cVQ28SJ4e a0pWPrmA6TWZQcuWaHRvo5zBGp6ysrgsWkGq//MmwH6IgrKhDBcRibCvZvSCtcfm2vxR GBI93R5PmPRNCUmQaZjn0q4dgftfOhigH2DOH6KG/bcov9zuvcVVdkaAFVJ/mUAxLRtm lh2O2KB4ZCU8+bS5xMz4YPan7JGTyEASmEq3iGspkYChg9nSB8+HFOleQuKAnflTztsM YxQw== X-Gm-Message-State: ALyK8tLRahM3RcfLpNe1/NY4LRV59kymD5rkEJXVJ/RJPft6zm9mLKYwbdT75mZw1j1LTw== X-Received: by 10.194.191.135 with SMTP id gy7mr10973018wjc.125.1466358955318; Sun, 19 Jun 2016 10:55:55 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id x194sm4521609wmf.13.2016.06.19.10.55.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jun 2016 10:55:54 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160619171531.GH5875@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22d 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:204536 Archived-At: On 06/19/2016 08:15 PM, Alan Mackenzie wrote: > Yes, that is indeed the case. Sorry I didn't spot that earlier. The > same applies to an ordinary string, too, provided there are enough > escpaed new lines. So some operations in CC Mode are indeed O(buffer length)? That sounds like a problem. >>> A critical reason, which I've told you before, is that on any buffer >>> change, the syntax-propertize-function mechanism blasts all s-t >>> properties out of existence from the point the change is made onwards. >>> This is wasteful of run-time, given that these properties are quite >>> expensive to apply. > >> They can't be too expensive, considering other language modes, which do >> use syntax-propertize-function, exhibit fewer performance problems than >> CC Mode, even at the same file sizes. > > The speed problems with CC Mode are not to do with the way it puts text > properties on characters. Anyway, that's recently got better. :-) My point is, the "critical reason" can't be too critical, considering you've been living with bigger problems for quite a while. >> And if the automatic removal of syntax-table properties would lose >> important information, you could save them to a separate structure. > > I could, but why go to all the hassle when handling these properties in > before/after-change-functions works so well? Is O(buffer length) "working well"? > Consider the following non-unusual case. In C++ Mode we have nested > template delimiters, thusly: > > A B C D > < < > > > > They each have parentheses syntax-table text properties such that A > matches D and B matches C. You can, for example put point at A, do > C-M-n, and you will get to after D. > > Suppose you delete the < at A, and move point to D. What will now > happen if you do C-M-p? Scan error? > With a syntax-propertize-function instead of the current > before/after-change-functions, I simply can't picture what would happen. The same. a) By the time you move point to D, font-lock has most likely run, and the current visible area of the buffer is already syntax-propertized (this is how this problem was solved in Emacs <25). b) In addition to that, scan_lists now applies syntax-table properties by calling syntax-propertize-function > Why do we need > such a general abstraction, anyway? before/after-change-functions > already form a good scheme for applying and removing these properties. Because just by the virtue of having before/after-change-functions, we can be sure that a given position is syntax-propertized. The only way we could, without adding additional abstraction, is by agreeing that all buffers must be syntax-propertized in their entirety after before/after-change-functions run. And that is just too damn wasteful. > Changing CC Mode to use syntax-propertize-function would require a > substantial amount of design work, assuming such were possible. There > doesn't seem to be a good reason to do this. One reason would be for you to get a handle on what it does, and the design benefit that follow. Maybe you would discover an even better design along the way, who knows.