From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Several Major Modes. [Was: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.] Date: Fri, 15 Nov 2019 00:11:17 +0200 Message-ID: <4eb06378-b6ce-e6b6-5939-b1cb34267a9c@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="108409"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 14 23:11:58 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 1iVNLJ-000S4X-Uw for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 23:11:58 +0100 Original-Received: from localhost ([::1]:34140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVNLI-0008Ef-Qe for ged-emacs-devel@m.gmane.org; Thu, 14 Nov 2019 17:11:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56358) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVNKl-0008EW-Gc for emacs-devel@gnu.org; Thu, 14 Nov 2019 17:11:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVNKk-0002hi-5J for emacs-devel@gnu.org; Thu, 14 Nov 2019 17:11:23 -0500 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:34712) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iVNKj-0002hO-TY for emacs-devel@gnu.org; Thu, 14 Nov 2019 17:11:22 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id e6so8646937wrw.1 for ; Thu, 14 Nov 2019 14:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iRpVnAiFLxAAskgU8QxW7fw0Nn/5NVfiG4XZKgHjWls=; b=UJWB/AODYVlNwJraF+/wTfGoWEhoDHuffrMBicg0ypQ1qA4eG2BQYTb6kjDL8YrgjC yTa9/aOM1YJOL9iU7S0h+sgPbfAfoQx/6p3l9/EyF33TwU6jUBA0qHQmgxlh6sexBKFx LiDnkOoRQV2MiThn2jRQ8o3Jw4cBDXJwCgberHkWGNZBB4jIuk3TAPy1D1bbUoevoj2+ AmNvHQ9fi4f8fKsEOKdtMJElarXn6PDqc9NqQGEyXa03UeMdE9sqG9NEe+K/ponjL1Xm X7nqMQO6YxRi5jFwLwwZi3Pv3+68IdU0XLOswHMd9VZEzt+4JObw3lmib4rcFbMEVfQV iuMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iRpVnAiFLxAAskgU8QxW7fw0Nn/5NVfiG4XZKgHjWls=; b=WhMTqF8OuPfq6nnd954zyjAVq7yizQiwpQ63512x6NWE9Oy7f2l57anyffeu0+J/mP Px6RUnWki6lGUHTt4rU6am0RrdxVCLVPnWSVhNpMyKbch3/jK7/xu9YSnq+TEJsWQDZ7 6w/Xeau/XykFnw+MmFDYsrx86ENu7FJRqkzzrYLMTYO2rVqnwvfK0K1wUyiPj3cQ7JMH DTarwjyC1SHUWNoUW/Qre/I4CWdhk82riwyuRijjxQoZeM1PDY3LYu6BhBjON2NCKXk1 ISUN+J+lxZDr4mgIBtc4x+fP/5chtOuSVOs3lmEUbmK4r2ZSp+GV/TRxxusFItM7tDFJ dc7g== X-Gm-Message-State: APjAAAWMqG2AcI3UbtwM+B0Ot86oXmxBdUs5tnIbbB54OfLd8VlXepov jsiZQ28C1SOwjEach1n+N8I4PKbuYXM= X-Google-Smtp-Source: APXvYqy5UyqgzeDlVkzEvc7tjZQ2hf7xAvES38+QOYDUuB05VEBhZpz8E2xVNOCEcNKuV4k6MnsmFg== X-Received: by 2002:a5d:50c3:: with SMTP id f3mr1314783wrt.14.1573769479872; Thu, 14 Nov 2019 14:11:19 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id 189sm8448552wmc.7.2019.11.14.14.11.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Nov 2019 14:11:19 -0800 (PST) In-Reply-To: <20191114212454.GD4297@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42a 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:242208 Archived-At: 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 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. Regarding "new type of local variable", mmm-mode already tracks something like that. >>>> 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. 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)? 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.