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: Fri, 15 Nov 2019 20:10:16 +0000 Message-ID: <20191115201016.GA5257@ACM> References: <20191109144026.20810.76129@vcs0.savannah.gnu.org> <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> 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="232687"; 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 Fri Nov 15 21:10:30 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 1iVhvK-000yKR-7F for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 21:10:30 +0100 Original-Received: from localhost ([::1]:44804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVhvI-0004oI-Qq for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 15:10:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41358) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVhvB-0004me-T9 for emacs-devel@gnu.org; Fri, 15 Nov 2019 15:10:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVhvA-0004FS-FB for emacs-devel@gnu.org; Fri, 15 Nov 2019 15:10:21 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:13181 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iVhvA-0004Eq-4L for emacs-devel@gnu.org; Fri, 15 Nov 2019 15:10:20 -0500 Original-Received: (qmail 1996 invoked by uid 3782); 15 Nov 2019 20:10:18 -0000 Original-Received: from acm.muc.de (p4FE1598B.dip0.t-ipconnect.de [79.225.89.139]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 15 Nov 2019 21:10:16 +0100 Original-Received: (qmail 5287 invoked by uid 1000); 15 Nov 2019 20:10:16 -0000 Content-Disposition: inline In-Reply-To: <4eb06378-b6ce-e6b6-5939-b1cb34267a9c@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:242247 Archived-At: Hello, Dmitry. On Fri, Nov 15, 2019 at 00:11:17 +0200, Dmitry Gutov wrote: > On 14.11.2019 23:24, Alan Mackenzie wrote: > > Hello, Dmitry. > > On Thu, Nov 14, 2019 at 00:33:33 +0200, Dmitry Gutov wrote: > > [ .... ] > >>>> In mmm-mode context, however, we apply definite boundaries to the > >>>> region chunks. Here's an example of some Noweb code: > >>>> https://en.wikipedia.org/wiki/Noweb#Example_of_a_simple_noweb_program > >>>> The inside of hello.c block would be narrowed to. > >>> I think I've said this before, but I don't think narrowing is the right > >>> tool for that task. I don't think there is a suitable tool in Emacs at > >>> the moment. > >> *shrug* We do the best with what we have. > > Why can we not formulate something better, an enhancement to the Emacs > > core which would support several major modes properly? I have made > > proposals in this area before, but I think they were to grandiose to be > > implementable. > > What seems to be needed is a way of partioning a buffer into several > > sub-buffers (which I have called "islands" in the past), and having a new > > type of local variable, one valid in exactly one sub-buffer. More or > > less. > 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. > .... or, if we absolutely can't make it work, add a new element to > prog-indentation-context which will be a function that would return the > bounds of the current chunk. Or something like that. > 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. > >>>> Now, I have remembered that CC Mode calls widen from many places > >>>> already, so it already is problematic for using in a context like > >>>> that. > >>> It does, yes. Users also use widening and narrowing. > > I believe these problems won't go away, and there will always be > > conflicts between CC Mode (as it is) and mmm-mode (as it is). > I think we should also try to understand whether making CC Mode play > nice to doable/feasible, and for what uses. Like, I think it can work > (more or less) already when it's the primary major mode (meaning the > buffer starts and ends with it), so the embedded chunks are all other > modes. 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. > 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. So I don't see why not, once the problem with the syntax-table text properties is solved. > By answering these questions we can temper our expectations and come up > with a practical plan. > Doing nothing is also a valid choice, BTW, since for many uses replacing > c-mode with js-mode works pretty okay. I've been recommending it to > MMM-mode users. That's a rather rough workaround. It would be better if we could solve the problems. -- Alan Mackenzie (Nuremberg, Germany).