bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Thu, Jun 25, 2020 at 21:19:11 +0300, Dmitry Gutov wrote:
> Hi Alan,

> On 25.06.2020 21:07, Alan Mackenzie wrote:

> > The purpose of this cache is to avoid repeated scanning from BOB.
> > Your proposed continual splatting of it would remove the benefit of
> > it entirely.

> That's unfortunate.

Indeed.  Let's assume that keeping it working is a requirement here.

> Guess the only thing that remains for me here is to express a wish for a 
> syntax-ppss based design here.

> Because mmm-mode knows how to deal with major modes based on it, as a group.

How about enhancing mmm-mode to handle any major mode, rather than a
restricted subset?

> >>> It would work fine with the current patch, together with calls to
> >>> initialise the mechanism.  What precisely is the problem in mmm-mode?

> >> That there is no good place to plug in your new functions.

> > That would appear to be a deficiency in mmm-mode.

> > Does mmm-mode not call js-mode when that is one of the submodes?  If it
> > doesn't, then why not add a general init function-variable/hook/whatever
> > into which initialisations can be plugged?

> It does not pick up each and every hook.

> If it did, though, it would only call your before-change-functions 
> inside js-mode regions, but it would have ignored them in HTML and CSS 
> regions. Which doesn't appear to be what you want anyway.

Then why not do in mmm-mode what I'm doing in CC Mode, mhtml-mode and
js-mode, i.e. add ad hoc code to handle precisely the case of js-mode?

It's not very nice, but it helps to analyse in the abstract how we
reached the point we are at.  That abstract reason is js-mode using part
of CC Mode without initialising it.  This is bound to lead to trouble,
and it has lead to trouble.

> >> And, in general, to have per-mode before-change-functions contents.

> > There's no problem with before/after-change-functions.  They're the
> > canonical way to react to buffer changes.

> They're not very manageable, from mmm's point of view. And like the 
> current example shows, it's not obvious what to do with such hooks 
> outside of submode regions of major modes that added them.

Like I said earlier on in the thread, making several major modes in a
buffer work is problematic in Emacs, and we really want better support
from the C core for it.  Here we seem to want "global" and "mode-local"
before-change-functionses.

-- 
Alan Mackenzie (Nuremberg, Germany).