From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Several Major Modes. Date: Sat, 16 Nov 2019 13:10:07 +0000 Message-ID: <20191116131007.GB6711@ACM> References: <20191109144027.DDC3720927@vcs0.savannah.gnu.org> <38328d99-23c8-7ba7-a23d-e70ac0aab67a@yandex.ru> <20191111203445.GA5135@ACM> <7497e71d-bab6-fa04-bbc4-f52fadeda16d@yandex.ru> <20191113211936.GB4942@ACM> <6fc930a1-eb47-9e54-8752-8cf7ff041586@yandex.ru> <20191114212454.GD4297@ACM> <4eb06378-b6ce-e6b6-5939-b1cb34267a9c@yandex.ru> <20191115201016.GA5257@ACM> <4b4465c2-b148-b05f-2eb9-863d4548c672@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="225127"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 16 14:10:37 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iVxqU-000wOG-VA for ged-emacs-devel@m.gmane.org; Sat, 16 Nov 2019 14:10:35 +0100 Original-Received: from localhost ([::1]:48140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVxqT-0003kW-Nd for ged-emacs-devel@m.gmane.org; Sat, 16 Nov 2019 08:10:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39000) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVxq8-0003k9-VW for emacs-devel@gnu.org; Sat, 16 Nov 2019 08:10:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVxq7-0002VV-KL for emacs-devel@gnu.org; Sat, 16 Nov 2019 08:10:12 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:41176 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iVxq7-0002VD-9o for emacs-devel@gnu.org; Sat, 16 Nov 2019 08:10:11 -0500 Original-Received: (qmail 84362 invoked by uid 3782); 16 Nov 2019 13:10:09 -0000 Original-Received: from acm.muc.de (p2E5D55F4.dip0.t-ipconnect.de [46.93.85.244]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 16 Nov 2019 14:10:07 +0100 Original-Received: (qmail 6833 invoked by uid 1000); 16 Nov 2019 13:10:07 -0000 Content-Disposition: inline In-Reply-To: <4b4465c2-b148-b05f-2eb9-863d4548c672@yandex.ru> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:242255 Archived-At: Hello, Dmitry. On Fri, Nov 15, 2019 at 23:45:44 +0200, Dmitry Gutov wrote: > On 15.11.2019 22:10, Alan Mackenzie wrote: > >> There are options. We'd have to decide on a suitable model, calling > >> them islands or whatever, but I think the first approximation is to > >> either make sure narrowing is available for this purpose .... > > You also need to make sure narrowing is available for any purpose > > required by a major mode. > Eh, I think it's "available" already, but I'd have to see specific examples. Oh good! I have to admit I haven't actually seen MMM Mode running, or at least I don't remember it. > The problem which triggered this discussion is that *something* called > font-lock rules from a narrowed buffer directly. But that's not a > "purpose required by a major mode". > >> Regarding "new type of local variable", mmm-mode already tracks > >> something like that. > > I was envisaging something at the C level, where different regions of a > > buffer would have different values of variables, without needing the > > continual swapping at the Lisp level. Maybe such a thing isn't needed. > I'd been told that even a C-based implementation is unlikely to make > things much faster. Anyway, it would be a perf optimization, and we > could get to it later. OK. > > It can't work if any external Lisp corrupts its syntax-table text > > properties. This is what syntax-ppss-flush-cache (on > > before-change-functions for many modes) would do if there were a non-nil > > syntax-propertize-function at the time. This may be the biggest problem > > to getting CC Mode integrated into MMM Mode. > mmm-mode sets its own syntax-propertize-function that calls major mode > specific syntax-propertize-function's over their respective > chunks/subregions. So, in principle, that should work fine. As long as > nobody calls 'widen' unexpectedly. I've taken a closer look at the functions in syntax.el, and I think you're right. The removal of the syntax-table text properties happens up to END, not to EOB. It would merely need syntax-propertize-function to be nil whenever anything involving the CC Mode region (including fontification) happens. > >> Is it feasible to support embedded chunks? To support chunks with > >> incomplete pieces of code (which are e.g. included conditionally by the > >> surrounding template)? > > Well CC Mode already supports preprocessor macros and (for C++) raw > > strings, which are syntactically somewhat and very different from the > > enclosing code. > I'm not sure it's the same. Like, would CC Mode cope with a region > starting with closing brackets, etc. This might not be a frequent > situation, but at least it shouldn't blow up. Maybe having several sets of syntax-table text properties in a buffer, one set for each sub-buffer, would help. I devised and half-implemented such a facility back in 2017, calling it "indirect text properties". To switch to a different set of properties, you would merely have to set (or bind) a dynamic variable. With this, I could set whitespace syntax-table props all over the non-CC Mode regions while CC Mode is "in scope", thus making syntactic stuff and fontification easy. -- Alan Mackenzie (Nuremberg, Germany).