From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#41897: 28.0.50; JavaScript comment filling with mhtml-mode Date: Wed, 24 Jun 2020 02:11:31 +0300 Message-ID: <4c6a9c40-a72c-1413-4e08-c7097f8bc407@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="12557"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: Simen =?UTF-8?Q?Heggest=C3=B8yl?= , 41897@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 24 01:12: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 1jns5J-00038l-6z for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jun 2020 01:12:09 +0200 Original-Received: from localhost ([::1]:46334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jns5I-0004PK-9P for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Jun 2020 19:12:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50824) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jns5C-0004Ox-Aw for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2020 19:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54093) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jns5C-0007Hc-1n for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2020 19:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jns5B-0000yV-Sr for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2020 19:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jun 2020 23:12: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.15929539053724 (code B ref 41897); Tue, 23 Jun 2020 23:12:01 +0000 Original-Received: (at 41897) by debbugs.gnu.org; 23 Jun 2020 23:11:45 +0000 Original-Received: from localhost ([127.0.0.1]:37406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jns4v-0000y0-5k for submit@debbugs.gnu.org; Tue, 23 Jun 2020 19:11:45 -0400 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:52447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jns4q-0000xl-J7 for 41897@debbugs.gnu.org; Tue, 23 Jun 2020 19:11:44 -0400 Original-Received: by mail-wm1-f44.google.com with SMTP id q15so400748wmj.2 for <41897@debbugs.gnu.org>; Tue, 23 Jun 2020 16:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uShy4GsGCvjL+K9BnoUzMp3VTeDfLn5kTmbJN6PILWo=; b=Y93Mz5U25hGW4xBjXihgk6rBVyzU6vy17y+L+sJtXjU7myigoYlWjIA6K0aF0C1WwW 0eC1R6DPcz2fTBg1drN7tD1L9vWHreFAnR9R9KS1f3sZdj5JZ0cxZAId6jskyHnLOOGp qVvYtNxBjcBPQUyOr8dSEV7M0Mfgd0bCeezislHOmxi4h3jCA9CGhdjy9zUj7NNoNr/X rdhjufYCbR/gbECi+w/Xze5RjOLLCiAutvskOxukdE0g2kG/FsAMBxQom8QFzgpg9UMf FyyXVhx7wmpSNH4DqQ3gFdwlJpnSiFhbZBBwx8Ko2Ntw5KMCzQaP6rivEI5hQK731rHE 3eqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uShy4GsGCvjL+K9BnoUzMp3VTeDfLn5kTmbJN6PILWo=; b=GJOQyDIj8eMip25V1c7n4NadyZNSHFFnENMHKo0kQeXd6HAGAmWPw1IRGiE2OhNhXb pdsTpawZFTXH+JsddNlPAbMmC+C/+jSxSZCuAjvLZ+faYT09MtR4DUBAZR7HuxARVTzQ hHSfu+4TvB3ck4lYtHbyeyJW9n4UUUFFty+YF/czP8xDWXJwkU8IKKNgq31gyeY3MXGk Rl14x/ZF+COFDbN1rx8+mDHgclsFahFjJVrp1FfxR6zgUGAPcnkyl92hkAssM0l1c6Fn 0I9xs+GlCQfm14fXTBZzSL2M1i21/vp7DKJZkiByL1+1mQ6MIGrOsQYG1cErCADwFy2x iHFg== X-Gm-Message-State: AOAM5327FlEbudzjnSJ8ZwzStnrgUJJGlMW1zdZsNlxZSKzTOfbL8Ynk fOORjErNj4Pia8oT7rI7UEVcRULo X-Google-Smtp-Source: ABdhPJygCZ8LpnHM3ePNymckY+gWlbb/4OnEVB82mS3R935fhCwFCQedEoZKtOfw6DcpShgv3NKoZg== X-Received: by 2002:a1c:98cc:: with SMTP id a195mr26531323wme.89.1592953894163; Tue, 23 Jun 2020 16:11:34 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id n8sm21053322wrj.44.2020.06.23.16.11.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 16:11:33 -0700 (PDT) In-Reply-To: <20200623191713.GC6957@ACM> Content-Language: en-US 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:182330 Archived-At: On 23.06.2020 22:17, Alan Mackenzie wrote: >> But isn't CC Mode confused by chunks of text with a totally different >> syntax? > > It might well be, probably is. But this isn't CC Mode we're talking > about - just a tiny part of its low level functionality, namely the bit > dealing with literals and filling them. So this cache is really serving the filling functionality only in this case. >>>> 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. > 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. One fewer before-change-functions element is also nothing to sneeze at. >> js-mode can be one of its submodes. c-mode as well, but none of CC Mode >> family of major modes ever worked okay with it, I think. > > Having several major modes in a single buffer has always been problematic > in Emacs. Personally, I think there needs to be amendments in the > low-level C code to support it properly, but I'm not able to do this work > on my own, and there doesn't seem to be enough enthusiasm on other > people's part to help out. We've learned to deal with most other major modes and features in mmm context. >> 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. >>>> 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. But that's an mmm-mode feature anyway.