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

[Dmitry Gutov]

Hi Alan,

On 25.06.2020 21:07, Alan Mackenzie wrote:

> > That's not true. Like you confirmed, c-fill-paragraph refers to that
> > cache multiple times. We'll only make sure the cache is reset in the
> > beginning.
>
> OK, first of all, I think I was mistaken in saying c-literal-limits is
> called several times.  I think it's just called once per filling action.
>
> But if it were called several times, it would likely need to be updated
> at every buffer change between calls.
>
> 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.

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.

> > > 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.

> > 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.