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: Several Major Modes. [Was: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.] Date: Thu, 14 Nov 2019 21:24:54 +0000 Message-ID: <20191114212454.GD4297@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> 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="183823"; 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 Thu Nov 14 22:26:01 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 1iVMcq-000laQ-JY for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 22:26:00 +0100 Original-Received: from localhost ([::1]:33836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVMcp-0007EY-FY for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 16:25:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48019) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVMbs-00064m-4D for emacs-devel@gnu.org; Thu, 14 Nov 2019 16:25:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVMbq-0001ce-MD for emacs-devel@gnu.org; Thu, 14 Nov 2019 16:24:59 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:59607 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iVMbq-0001cI-Cw for emacs-devel@gnu.org; Thu, 14 Nov 2019 16:24:58 -0500 Original-Received: (qmail 95550 invoked by uid 3782); 14 Nov 2019 21:24:55 -0000 Original-Received: from acm.muc.de (p4FE1564A.dip0.t-ipconnect.de [79.225.86.74]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 14 Nov 2019 22:24:54 +0100 Original-Received: (qmail 19662 invoked by uid 1000); 14 Nov 2019 21:24:54 -0000 Content-Disposition: inline In-Reply-To: <6fc930a1-eb47-9e54-8752-8cf7ff041586@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:242203 Archived-At: 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. > >> 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). > It's a different thing. Strategically undoing interactively applied > narrowing is not hard. -- Alan Mackenzie (Nuremberg, Germany).