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

[Alan Mackenzie]

Hello, Dmitry.

On Thu, Jun 25, 2020 at 22:28:17 +0300, Dmitry Gutov wrote:
> On 25.06.2020 22:13, Alan Mackenzie wrote:

>  >> That's unfortunate.

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

> Still, buffers that user mixed modes are usually not so big as some of
> the files we have in src/*.c. So even forgoing caching might result in
> a satisfying user experience 98% of the time.

Sluggish performance isn't about "usually" and 98% of the time; it's
about unusual constellations and the other 2%.

[ .... ]

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

> That would be something every user that configures a submode class using 
> js-mode have to be aware of. That's not easy to document, or even if we 
> made sure it's documented, to be sure that users read it.

Are you telling me that mmm-mode couldn't keep a watch out for js-mode,
leaving other libraries untroubled?  Again, the trouble here appears to
arise from using something (a mode) without first initialising it.

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

> These do seem to be the options: some C core support (though I'm not 
> clear on the particulars of the proposed design), or switching from 
> ad-hoc caches to syntax-propertize-function and and associated 
> syntax-ppss cache.

The syntax-propertize-function approach is poor design.  It restricts the
use of the syntax-table text property too much.  syntax-ppss has had a
troubled history and doesn't do the right thing in narrowed buffers.  It
advertises itself as a magic wand which does everything, but when you've
been enticed into committing your SW to it, you then find out it's less
than magic, and you've got to call ugly functions by hand at strange
times, and are restricted in how and when you can use it.

-- 
Alan Mackenzie (Nuremberg, Germany).