From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 18:42:29 -0500 Message-ID: References: <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <20171202202855.GA22133@ACM> <6a612831-a73f-2223-822f-7d594ebdff30@yandex.ru> <20171203145446.GB5531@ACM> <20171203222650.GB3907@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512344604 9348 195.159.176.226 (3 Dec 2017 23:43:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 23:43:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Tom Tromey , Dmitry Gutov , Vitalie Spinu , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 00:43:17 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLdul-0001xd-Mx for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 00:43:15 +0100 Original-Received: from localhost ([::1]:40552 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLdut-00050d-3B for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 18:43:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLduH-00050X-Ds for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:42:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLduE-0001yx-BG for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:42:45 -0500 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:6544) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLduE-0001yT-4U for emacs-devel@gnu.org; Sun, 03 Dec 2017 18:42:42 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EfBwCfiyRa/yLsjBhcHQEBBQELAYM8g?= =?us-ascii?q?VSDW4tfjgABgXwUIAGYYQqFNQQCAoUqRBQBAQEBAQEBAQEDaCiFJAEEAVYjBQs?= =?us-ascii?q?LDiYSFBgNJIotCKorilQBAQEHAgElg0GIdIsZBZMaj1KPR4gBiUOHXJZNgTo2I?= =?us-ascii?q?4FNMhoIMIJkglEcGYFsI4plAQEB?= X-IPAS-Result: =?us-ascii?q?A2EfBwCfiyRa/yLsjBhcHQEBBQELAYM8gVSDW4tfjgABgXw?= =?us-ascii?q?UIAGYYQqFNQQCAoUqRBQBAQEBAQEBAQEDaCiFJAEEAVYjBQsLDiYSFBgNJIotC?= =?us-ascii?q?KorilQBAQEHAgElg0GIdIsZBZMaj1KPR4gBiUOHXJZNgTo2I4FNMhoIMIJkglE?= =?us-ascii?q?cGYFsI4plAQEB?= X-IronPort-AV: E=Sophos;i="5.45,356,1508817600"; d="scan'208";a="11086842" Original-Received: from 24-140-236-34.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([24.140.236.34]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2017 18:42:36 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id BB4F7AE0F2; Sun, 3 Dec 2017 18:42:29 -0500 (EST) In-Reply-To: <20171203222650.GB3907@ACM> (Alan Mackenzie's message of "Sun, 3 Dec 2017 22:26:50 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 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:220669 Archived-At: >> > I don't rate restrictions on the use of Emacs primitives to be minor. >> I think there's a fundamental misunderstanding abut Dmitry's suggestion >> here: his proposal does not restrict the use of any primitive anywhere. > You say there's no restriction happening, then go on to detail the > restriction that is to be put in place. ;-) I have no idea what you're talking about. Where did you see a restriction? There are only guidelines, no restrictions. > Typically the code does need to know about "distant" chunks. The years of experience with mmm-mode, as well as the more recent experience with mhtml-mode disagree with this. > For example if point is after an embedded AWK Mode script in > shell-script-mode, C-M-a will need access to the buffer part before > the AWK Mode interlude. This already works and won't be affected by the proposal. >> (add-hook 'syntax-propertize-extend-region-functions >> #'syntax-propertize-multiline nil t) > All constructs in CC Mode languages are "multiline". So what? >> when you find (and put the syntax-table property on) the <...> pair. > Why not just put that property on the entire buffer? Or, if > syntax-multiline is intended to flag up just one construct, it won't cope > well with nested (or overlapping) constructs. As I said, you don't have to use that. You can write your own syntax-propertize-extend-region-function any which way you like. >> Of course, it's not the only possible way to do it. It's just the way >> I solved similar problems in perl-mode and sh-mode. > How is that going to help when a closing template delimiter is deleted? It will cause the re-propertization to be done from the matching opening delimiter (at least, if you've set things up correctly, of course: syntax-propertize itself has no idea about those delimiters). > One problem is the vagueness in the documentation of > syntax-propertize-extend-region-functions. Are these functions called in > before-change-functions or a-c-functions? Obviously, in my case above, > they would be needed in b-c-f, otherwise they wouldn't notice the ">" > being killed. The text between < and > is marked, what when BEG falls in the middle, syntax-propertize-extend-region-functions will know without having to have access to the ">" (so it doesn't matter if it's already been deleted or not). > But they need to be called in a-c-f too, in case the > change is adding "> >", when the code needs to search back to the earlier > two "<"s, which now have become "dirty" when they weren't previously. This kind of complexity disappears in syntax-propertize's approach. > syntax-propertize splats all syntax-table properties after a change > point, if I understand correctly. That means they must at some point > soon be regenerated[*]. This will be expensive in a large buffer. This *can* be expensive, but they're only regenerated lazily, so typically it's not a problem. We have many years of experience in many different major modes to say that it's likely not to be a problem. > Several differences in performance that "hardly matter" can add up to > something substantial. "can", indeed. My experience makes me confident it won't happen. Stefan