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: Thu, 25 Jun 2020 21:19:11 +0300 Message-ID: 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> <20200625180722.GC10342@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="91260"; 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 Thu Jun 25 20:20: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 1joWTq-000Ne8-MM for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 20:20:10 +0200 Original-Received: from localhost ([::1]:52344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1joWTp-0005fW-7i for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Jun 2020 14:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1joWTi-0005f4-FB for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57830) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1joWTi-0007iX-4d for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1joWTh-0006Be-W7 for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2020 14:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jun 2020 18:20: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.159310916223733 (code B ref 41897); Thu, 25 Jun 2020 18:20:01 +0000 Original-Received: (at 41897) by debbugs.gnu.org; 25 Jun 2020 18:19:22 +0000 Original-Received: from localhost ([127.0.0.1]:41143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joWT4-0006Ai-4x for submit@debbugs.gnu.org; Thu, 25 Jun 2020 14:19:22 -0400 Original-Received: from mail-ed1-f68.google.com ([209.85.208.68]:40200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joWT2-0006AT-Ki for 41897@debbugs.gnu.org; Thu, 25 Jun 2020 14:19:21 -0400 Original-Received: by mail-ed1-f68.google.com with SMTP id b15so4945798edy.7 for <41897@debbugs.gnu.org>; Thu, 25 Jun 2020 11:19:20 -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=9w83IJ6yZtAFbeSwshn7SUlxH6cvBstzeo8FgaBbfG8=; b=iKw25NPXyIvHhckPNrnfLG9GW3wbkOlr07au1p/CQpSqXIsAHcSv3WLz0JrVjrlHYn dphuKs9ty69g1GB+MaQL7ht+VPDoFGiTF0t9p+IzIGPMxqf870C0sQLNfxXz3gYOqyc5 16QY1QuKS4a3ZW6gKcPrtELIxPS+Nl5n9B9SxUxgGS6UrPkcIEW1qR1GntH5cVZw1nX2 xcd+2jpEv76RuOG3vzq/TKYSgNfboLdYK0CilpmGfPZx3puLZkwEzDwzS2jtSnzAJAH6 XSpc/ue2/4ltK6c1BeoAJ3aAcAPIhnaMIawmi8QHeGFYRGeNuaMon9X3UWe7I3y7+b0O mjLw== 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=9w83IJ6yZtAFbeSwshn7SUlxH6cvBstzeo8FgaBbfG8=; b=FmNJrtGYdpZ9Pz4IyVwemQFCumFfIuyumjzucwrezAWl0gm5KxHUBLBYxb6MDnSqDn ejL36a5sAzcxZ1HMC9ivocVtYEFGSKrtDrCTh7kE3wFHne9wvmeIQnWHqQLf1C1i6da8 bikANWOvm425Wi2jxtWYu65iG9hoO0ygc/OoYMHef/dm1HZH9nbwQW/Pl7wRc/vNESj6 WOMlzzYZwmqktl77BT/0QtGJYUQIh5vXRQSVlh+BuytjpZ4Ufs6mHo5Tus6kvuWDdO4N H+R+4XmwETZvqYB07NqF5ayQaKoX9TqZ82Lw/oOphh5+R4w1ubERdU1zVYeS6o4TVUQl 9gSg== X-Gm-Message-State: AOAM530Nm4n01r/lGJNsb3fCnLvqMfh7lAVAkKTa39sYxBUYMUTfHkNg Rd5as6Ka5rAi1JcBsv5/Kxwf33Ap X-Google-Smtp-Source: ABdhPJzLJW9HvvvdP6ppjE20tXW0dgXYMUodVKa97hhlx9OvsF7Qa2MUchSj4HWAn01iHQD72ekIGg== X-Received: by 2002:aa7:c90a:: with SMTP id b10mr33541749edt.198.1593109154575; Thu, 25 Jun 2020 11:19:14 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s5sm17381928eji.73.2020.06.25.11.19.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 11:19:13 -0700 (PDT) In-Reply-To: <20200625180722.GC10342@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:182383 Archived-At: Hi Alan, On 25.06.2020 21:07, Alan Mackenzie wrote: >> 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. That's unfortunate. Guess the only thing that remains for me here is to express a wish for a syntax-ppss based design here. Because mmm-mode knows how to deal with major modes based on it, as a group. >>> 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? It does not pick up each and every hook. If it did, though, it would only call your before-change-functions inside js-mode regions, but it would have ignored them in HTML and CSS regions. Which doesn't appear to be what you want anyway. >> 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. They're not very manageable, from mmm's point of view. And like the current example shows, it's not obvious what to do with such hooks outside of submode regions of major modes that added them.