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

Previous Next

Full log

Message #50 received at 41897 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode
Date: Thu, 25 Jun 2020 19:48:57 +0300

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.

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

And, in general, to have per-mode before-change-functions contents.

Previous Next

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