GNU bug report logs - #41897
28.0.50; JavaScript comment filling with mhtml-mode

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Simen Heggestøyl <simenheg <at> runbox.com>, 41897 <at> debbugs.gnu.org
Subject: bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode
Date: Thu, 25 Jun 2020 22:28:17 +0300

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.

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

I don't know how. before-change-functions don't make it easy.

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

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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.