From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Sun, 7 Aug 2022 14:13:36 +0000 Message-ID: References: <6ae35c9306ade07b4c45@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6471"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 16:14:52 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oKh3L-0001XM-Nm for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 16:14:51 +0200 Original-Received: from localhost ([::1]:35830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKh3K-00077L-K6 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 10:14:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKh2E-0006Dv-1q for emacs-devel@gnu.org; Sun, 07 Aug 2022 10:13:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29065 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oKh2C-0006ZL-0g for emacs-devel@gnu.org; Sun, 07 Aug 2022 10:13:41 -0400 Original-Received: (qmail 67520 invoked by uid 3782); 7 Aug 2022 14:13:37 -0000 Original-Received: from acm.muc.de (p2e5d5157.dip0.t-ipconnect.de [46.93.81.87]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Aug 2022 16:13:37 +0200 Original-Received: (qmail 5235 invoked by uid 1000); 7 Aug 2022 14:13:36 -0000 Content-Disposition: inline In-Reply-To: <6ae35c9306ade07b4c45@heytings.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293204 Archived-At: Hello, Gregory. On Sun, Aug 07, 2022 at 13:31:05 +0000, Gregory Heytings wrote: > > Major modes, like all Emacs Lisp programs, have, by design, access to > > the full range of Emacs's facilities. Should it make your task more > > difficult (and I don't see that it does), that's your problem, not the > > major modes' maintainers'. > I fear it is not my problem, no. > jit-lock-functions is an API, with a contract. CC Mode decided to break > that contract. Where, exactly are the terms of this supposed contract formulated? And which part of this supposed contract has CC Mode broken? I suspect that this "contract" is something implicit you have in your understanding of Emacs, shared by some other people, and that you have assumed that everybody else shares that understanding. Such conflicts have occurred before. > It is wrong that "arbitrary Lisp can be executed through > fontification-functions", as you said earlier. It is not wrong. If you disagree, point out where, say in the Elisp manual, these restrictions are imposed. > A function called from fontification-functions isn't supposed to > download a file, or to send an email, or to change a user option, or > to remove or create a file, or to remove or insert text in the buffer, > or to kill Emacs or a frame or a window or the current buffer, or to > change the window layout, and so on and so forth. That doesn't deserve a reply, so won't be getting one. > So far breaching that contract has not posed major problems, except of > course for CC Mode users, who had to bear its sluggishness. We now have a > new feature which assumes, and rightly so, that this contract is obeyed. This new feature deliberately breaks contracts, in particular the definitions of widen and narrow-to-region. That will, sooner or later, break existing code. Maybe this is necessary, but having read the bug threads, I didn't notice much effort being put into preserving these contracts. If you find CC Mode too sluggish for you (I don't), then configure it to be faster and inaccurate by setting font-lock-maximum-decoration. > This breaks CC Mode. CC Mode will cope. > >From where I stand, there are two options here: either CC Mode disables > the new feature (which is, on purpose, 100% backward compatible), or CC > Mode is fixed to obey the jit-lock-functions contract, and to become > compatible with the new feature (which will likely also, by side-effect > and as a bonus, fix the aforementioned sluggishness). -- Alan Mackenzie (Nuremberg, Germany).