emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Several Major Modes. [Was: master 7362554: Widen around c-font-lock-


From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]