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: Sun, 28 Jun 2020 03:18:15 +0300

On 27.06.2020 14:06, Alan Mackenzie wrote:
> Hello, Dmitry.
> 
> On Fri, Jun 26, 2020 at 00:20:07 +0300, Dmitry Gutov wrote:
>> On 25.06.2020 23:11, Alan Mackenzie wrote:
> 
>>> Sluggish performance isn't about "usually" and 98% of the time; it's
>>> about unusual constellations and the other 2%.
> 
>> Still, a slow-ish fill-paragraph is nowhere near as bad as, say,
>> slowdown during typing.
> 
> We're talking about a long pause at the end of each line when typing in
> a longish block comment whilst auto-fill-mode is enabled.

OK, that's an argument.

I'm inclined to believe it should be acceptably small for all such files 
in practice, but I don't have any solid data to back that up.

>>>>> 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.
> 
>> Sounds like special-casing js-mode, before-change-functions and this
>> particular function all together. Basically, like a magic constant in
>> the code.
> 
>> This is ultimately doable, but I'm not sure how to write a patch for it
>> which wouldn't leave me feeling dirty after.
> 
> If I understand correctly, there is already special case code for js-mode
> anyway, in mmm-erb.el.  The :creation-hook for js-mode is currently set
> to mmm-erb-mark-as-special, a function shared with ruby-mode.

Good find, in a way: to satisfy your requirement, :creation-hook is 
likely the property to use.

But the code you pointed to (mmm-erb.el) contains specialized major mode 
that uses js-mode, among other modes, to implement support for ERB, EJS 
and JSP templates, together with indentation logic.

It is also the only built-in example of a major mode in mmm-mode. 
Whereas people use js-mode also in other contexts, a lot of the time in 
configurations that they create themselves (called submode classes, 
which are then associated with existing major modes, to be used as 
"primary" mode, and file extensions).

As such, any user who creates such a configuration involving js-mode 
will need to be aware of c-foreign-init-lit-pos-cache and 
c-foreign-truncate-lit-pos-cache.

> Would it really be all that distressing to write a new :creation-hook for
> js-mode which additionally initialises the part of CC Mode which needs
> it?  We'd be talking about something like
> 
>      (defun mmm-js-init ()
>        "Doc string."
>        (overlay-put mmm-current-overlay 'mmm-special-tag t)
>        (c-foreign-init-lit-pos-cache)
>        (add-hook 'before-change-functions #'c-foreign-truncate-lit-pos-cache nil t))

It's not by itself distressing as long the one who needs to write it 
remembers and understands its necessity.

In any case, I tried this solution together with the patch you attached 
(assuming patching the code and evaluating the new contents of 
cc-engine.el should be enough to make it work), but it didn't help with 
the same scenario in html-erb-mode. It didn't make anything worse, though.

Since mmm-mode is actually out of scope of this bug report, though, 
perhaps I should stop with this thread of discussion.

Previous Next

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