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: Sun, 17 Nov 2019 16:03:26 +0000 Message-ID: <20191117160326.GA11551@ACM> References: <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> <20191116131007.GB6711@ACM> <12fbf5de-e4a8-cfc5-b92e-be368eb2c1f4@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="232590"; 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 Sun Nov 17 17:03:50 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 1iWN1d-000yHt-CV for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 17:03:46 +0100 Original-Received: from localhost ([::1]:54440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWN1b-0002VF-Pf for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 11:03:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60317) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWN1S-0002UH-7E for emacs-devel@gnu.org; Sun, 17 Nov 2019 11:03:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWN1Q-0000gE-Sw for emacs-devel@gnu.org; Sun, 17 Nov 2019 11:03:34 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:50060 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iWN1P-0000da-Jm for emacs-devel@gnu.org; Sun, 17 Nov 2019 11:03:32 -0500 Original-Received: (qmail 8529 invoked by uid 3782); 17 Nov 2019 16:03:29 -0000 Original-Received: from acm.muc.de (p4FE150B7.dip0.t-ipconnect.de [79.225.80.183]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 17 Nov 2019 17:03:26 +0100 Original-Received: (qmail 13422 invoked by uid 1000); 17 Nov 2019 16:03:26 -0000 Content-Disposition: inline In-Reply-To: <12fbf5de-e4a8-cfc5-b92e-be368eb2c1f4@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:242278 Archived-At: Hello, Dmitry. On Sun, Nov 17, 2019 at 14:48:35 +0200, Dmitry Gutov wrote: > Hi Alan, > On 16.11.2019 15:10, Alan Mackenzie wrote: > >>> 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. > I think we won't really know until there's a good change of CC Mode > working with MMM Mode, so then people could try and exercise various > features. And we'll see what works and what does not. Other than CC Mode's handling of syntax-table text properties, what precisely is hindering it working in MMM Mode? (That question's partly addressed at myself.) [ .... ] > >>>> 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. > It's an interesting suggestion, but a difficult problem. Like, if you > just swap the meanings of syntax-table text properties, it would make > syntax-ppss caches invalid without telling it. A better solution would > be to somehow integrate with it. Being more precise, with this idea there would be several sets of s-t properties present at the same time. Each would have a different symbol, e.g. gensyms like syntax-table-13, syntax-table-14, ..... The code in textprop.c would check the symbol 'syntax-table for a particular symbol property, which if set would cause it to substitute, say, syntax-table-13, and read/write that property instead. Fast, and only a bit inelegant. Naturally, all the low-level caches in syntax.c would need to be synchronised at the same time we bind the thing to syntax-table-13. The caches belonging to each individual MMM chunk (such as syntax-ppss caches) would be OK without change, since they would only be used while the chunk was current, and hence syntax-table-13 currently in use. Given how much in Emacs depends on syntax, this scheme might save a lot of work and a lot of workarounds in MMM Mode. If MMM Mode could be responsible for putting space syntax-table-13 properties on all chunks but the current one, it is possible major modes could be used in MMM Mode with only minimal adaptations to those major modes. Implementing this scheme would not be difficult. (As I said, it's half done already.) How would you feel about using it in MMM Mode, and do you see any difficult problems with it? > Anyway, you mentioned a real problem (for which I only have workarounds > thus far), but for now I was just asking whether an isolated > "incomplete" chunk would work okay. :-) Sorry, yes. I think working with an incomplete chunk would be difficult at the moment. With all the other chunks "spaced out", as suggested above, it would be easy, I think. -- Alan Mackenzie (Nuremberg, Germany).