From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode Date: Thu, 25 Jun 2020 18:07:22 +0000 Message-ID: <20200625180722.GC10342@ACM> References: <20200623083613.GA6957@ACM> <20200623162837.GB6957@ACM> <10235ec5-17c3-c281-b5ed-2c65a07bd02f@yandex.ru> <20200623191713.GC6957@ACM> <4c6a9c40-a72c-1413-4e08-c7097f8bc407@yandex.ru> <20200624174333.GA8870@ACM> <20200625163301.GA10342@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="38490"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Simen =?UTF-8?Q?Heggest=C3=B8yl?= , acm@muc.de, 41897@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 25 20:08:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joWIF-0009wO-3K for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 20:08:11 +0200 Original-Received: from localhost ([::1]:51172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1joWIE-0004CP-6k for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 14:08:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1joWI6-0004Bz-Ap for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:08:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1joWI6-0002ZL-15 for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1joWI5-0005sc-R4 for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jun 2020 18:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41897 X-GNU-PR-Package: emacs Original-Received: via spool by 41897-submit@debbugs.gnu.org id=B41897.159310845322564 (code B ref 41897); Thu, 25 Jun 2020 18:08:01 +0000 Original-Received: (at 41897) by debbugs.gnu.org; 25 Jun 2020 18:07:33 +0000 Original-Received: from localhost ([127.0.0.1]:41133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joWHc-0005rs-R9 for submit@debbugs.gnu.org; Thu, 25 Jun 2020 14:07:33 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:25989 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1joWHa-0005re-A4 for 41897@debbugs.gnu.org; Thu, 25 Jun 2020 14:07:31 -0400 Original-Received: (qmail 18982 invoked by uid 3782); 25 Jun 2020 18:07:23 -0000 Original-Received: from acm.muc.de (p4fe15761.dip0.t-ipconnect.de [79.225.87.97]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Thu, 25 Jun 2020 20:07:22 +0200 Original-Received: (qmail 11338 invoked by uid 1000); 25 Jun 2020 18:07:22 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182381 Archived-At: Hello, Dmitry. On Thu, Jun 25, 2020 at 19:48:57 +0300, Dmitry Gutov wrote: > 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. OK, first of all, I think I was mistaken in saying c-literal-limits is called several times. I think it's just called once per filling action. But if it were called several times, it would likely need to be updated at every buffer change between calls. The purpose of this cache is to avoid repeated scanning from BOB. Your proposed continual splatting of it would remove the benefit of it entirely. > >>> 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. That would appear to be a deficiency in mmm-mode. Does mmm-mode not call js-mode when that is one of the submodes? If it doesn't, then why not add a general init function-variable/hook/whatever into which initialisations can be plugged? > And, in general, to have per-mode before-change-functions contents. There's no problem with before/after-change-functions. They're the canonical way to react to buffer changes. -- Alan Mackenzie (Nuremberg, Germany).