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

[Alan Mackenzie]

Hello, Dmitry.

On Wed, Jun 24, 2020 at 02:11:31 +0300, Dmitry Gutov wrote:
> On 23.06.2020 22:17, Alan Mackenzie wrote:

[ .... ]

> >>>> And there's no way to just "reset" it to an appropriate value?

> >>> No.  Not without killing its utility as a cache.

> >> What do you mean? Even if the cache is reset at the beginning of a
> >> function, if the function refers to it multiple times, the first time
> >> should refill the cache, and the rest of the calls will be able to make
> >> use of it properly.

> > That's what I mean.  The cache persists over commands, reducing the
> > amount of recalculation needed, particularly for fast typing.  Refilling
> > it from scratch on every keypress would likely make it sluggish.

> Not on every keypress. Only when js-fill-paragraph is called. One-time 
> delay only when required.

But a substantial delay, involving (I think) analysing the code from BOB
each time.  The current working setup has a negligible delay at each
buffer change (and, of course, recalculation of cache entries only when
required).

> > Anyhow, it works fine at the moment, so why change it?

> The above scheme would require fewer references to CC Mode functions 
> from outside. js-mode support would automatically transfer to mhtml-mode 
> and mmm-mode with associated changes in them necessary.

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

> One fewer before-change-functions element is also nothing to sneeze at.

There's nothing wrong with having functions in
before/after-change-functions.  It's a standard Emacs programming
technique.

[ .... ]

> >> js-mode mostly works, aside from features like this one.

> > With the current patch, comment filling should work fine in js-mode.

> Above, I meant that js-mode mostly works fine with mmm-mode. And my 
> suggestion might make comment filling work there, too. Automatically.

It works automatically at the moment (with the current patch applied).  I
think you're saying again you don't want to be troubled by initialising
it.

> >>>> Have you considered adding variables that hold the cache to
> >>>> mhtml--crucial-variable-prefix as well? Would that make it work?

> >>> Not without the before-change function, no.  I'm trying to see what the
> >>> point of putting these variables into mhtml's crucial variables would be.

> >> Hopefully, it would make the submode regions inside independent
> >> "islands", so to speak. Each of them having its own cache structure
> >> (used or not).

> > Ah, OK.  So, buffer positions would be offsets from the island start, or
> > something like that.

> Not necessarily, but possibly. The key aspect is that the cache inside a 
> particular submode is not affected by user actions outside of its 
> bounds. Not directly, at least.

Well, when a cached holds buffer positions, something has to give -
either markers need to be used, or an offset from a variable position, or
something.

> But that's an mmm-mode feature anyway.

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).