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: Wed, 24 Jun 2020 17:43:33 +0000 Message-ID: <20200624174333.GA8870@ACM> References: <20200620171827.7855.qmail@mail.muc.de> <87d05ta8z9.fsf@simenheg@gmail.com> <20200622191750.GA11506@ACM> <20200623083613.GA6957@ACM> <20200623162837.GB6957@ACM> <10235ec5-17c3-c281-b5ed-2c65a07bd02f@yandex.ru> <20200623191713.GC6957@ACM> <4c6a9c40-a72c-1413-4e08-c7097f8bc407@yandex.ru> 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="66982"; 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 Wed Jun 24 19:44:10 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 1jo9RS-000HJG-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jun 2020 19:44:10 +0200 Original-Received: from localhost ([::1]:48728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jo9RR-0007gb-2f for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jun 2020 13:44:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jo9RK-0007gJ-P9 for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2020 13:44:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jo9RK-0006im-FM for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2020 13:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jo9RK-0000j8-DZ for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2020 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jun 2020 17:44:02 +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.15930206252750 (code B ref 41897); Wed, 24 Jun 2020 17:44:02 +0000 Original-Received: (at 41897) by debbugs.gnu.org; 24 Jun 2020 17:43:45 +0000 Original-Received: from localhost ([127.0.0.1]:38826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jo9R3-0000iI-5N for submit@debbugs.gnu.org; Wed, 24 Jun 2020 13:43:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:28894 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1jo9Qz-0000i3-57 for 41897@debbugs.gnu.org; Wed, 24 Jun 2020 13:43:43 -0400 Original-Received: (qmail 16651 invoked by uid 3782); 24 Jun 2020 17:43:34 -0000 Original-Received: from acm.muc.de (p4fe15a7c.dip0.t-ipconnect.de [79.225.90.124]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 24 Jun 2020 19:43:33 +0200 Original-Received: (qmail 8923 invoked by uid 1000); 24 Jun 2020 17:43:33 -0000 Content-Disposition: inline In-Reply-To: <4c6a9c40-a72c-1413-4e08-c7097f8bc407@yandex.ru> 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:182351 Archived-At: Hello, Dmitry. On Wed, Jun 24, 2020 at 02:11:31 +0300, Dmitry Gutov wrote: > On 23.06.2020 22:17, Alan Mackenzie wrote: [ .... ] > >>>> And there's no way to just "reset" it to an appropriate value? > >>> No. Not without killing its utility as a cache. > >> What do you mean? Even if the cache is reset at the beginning of a > >> function, if the function refers to it multiple times, the first time > >> should refill the cache, and the rest of the calls will be able to make > >> use of it properly. > > That's what I mean. The cache persists over commands, reducing the > > amount of recalculation needed, particularly for fast typing. Refilling > > it from scratch on every keypress would likely make it sluggish. > Not on every keypress. Only when js-fill-paragraph is called. One-time > delay only when required. But a substantial delay, involving (I think) analysing the code from BOB each time. The current working setup has a negligible delay at each buffer change (and, of course, recalculation of cache entries only when required). > > Anyhow, it works fine at the moment, so why change it? > The above scheme would require fewer references to CC Mode functions > from outside. js-mode support would automatically transfer to mhtml-mode > and mmm-mode with associated changes in them necessary. It sounds like you want to use a facility without initialising it. This feels a bit unreasonable. > One fewer before-change-functions element is also nothing to sneeze at. There's nothing wrong with having functions in before/after-change-functions. It's a standard Emacs programming technique. [ .... ] > >> js-mode mostly works, aside from features like this one. > > With the current patch, comment filling should work fine in js-mode. > Above, I meant that js-mode mostly works fine with mmm-mode. And my > suggestion might make comment filling work there, too. Automatically. It works automatically at the moment (with the current patch applied). I think you're saying again you don't want to be troubled by initialising it. > >>>> Have you considered adding variables that hold the cache to > >>>> mhtml--crucial-variable-prefix as well? Would that make it work? > >>> Not without the before-change function, no. I'm trying to see what the > >>> point of putting these variables into mhtml's crucial variables would be. > >> Hopefully, it would make the submode regions inside independent > >> "islands", so to speak. Each of them having its own cache structure > >> (used or not). > > Ah, OK. So, buffer positions would be offsets from the island start, or > > something like that. > Not necessarily, but possibly. The key aspect is that the cache inside a > particular submode is not affected by user actions outside of its > bounds. Not directly, at least. Well, when a cached holds buffer positions, something has to give - either markers need to be used, or an offset from a variable position, or something. > But that's an mmm-mode feature anyway. OK. -- Alan Mackenzie (Nuremberg, Germany).