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

[Alan Mackenzie]

Hello, Dmitry.

On Thu, Jun 25, 2020 at 19:48:57 +0300, Dmitry Gutov wrote:
> On 25.06.2020 19:33, Alan Mackenzie wrote:

> >> I imagine that would not be a significant problem for the rare cases
> >> that fill-paragraph is called in a JS region. Considering most of the
> >> contents in mhtml-mode buffers are not JS code, on average, that should
> >> tilt the scales in favor of parsing lazily, rather than affecting every
> >> character insertion.

> > The current patch does parse lazily.  You want to remove the benefit of
> > using this cache, no matter how small, for reasons I still can't grasp.

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

> >>> It sounds like you want to use a facility without initialising it.
> >>> This feels a bit unreasonable.

> >> That cache reset at the beginning of js-fill-paragraph could as well
> >> re-initialize the cache.

> > You're misusing the work "initialize" here.  If you initialise a
> > variable every time you read it, you might as well not have that
> > variable.

> Like explained above, not *every* time.

> >> It doesn't automatically work in mmm-mode. With my suggestion, it very
> >> likely would.

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).