From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Sun, 07 Aug 2022 09:03:09 +0300 Message-ID: <83o7wwy4iq.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11563"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, gregory@heytings.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 08:06:00 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 1oKZQG-0002ha-JI for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 08:06:00 +0200 Original-Received: from localhost ([::1]:50220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKZQF-0002CC-B8 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 02:05:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZNn-0000kr-6v for emacs-devel@gnu.org; Sun, 07 Aug 2022 02:03:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49762) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZNm-0003S7-Ei; Sun, 07 Aug 2022 02:03:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vbWcIu1pMt76KzPuUWz5jA0v0SiVxLMiAjHz8q2ZSAw=; b=mVJCXkc1/2BQ e1OssaSqcbUblp861Ai8rKi7zoLNYeDWf/EBcSZWeqMYWDGdI2ZWe3Bp8zfqjcGHWl7fS+cUvqqGc WVk48D/RGrSlFdYs4RqQ3qwHyapi9hth6NXRjS4ZufRyF2XnCIkMwpYWT9Zx6FVPq+aXV6yRzH5rk L0k9x/upX9KzQ9KFcO0Qtf8KBWpwvDTiOrVqRfYOpymqxKdZeuDfAQvZkw6DVEIfa0PFgwuTzEskq BFCQw4N5f7D0uXfNm87N3/nq/6mLQJBm0pHhqJP22Zzs1DjMXrHYNRDG222GmrPmESpqLgF9KWtCM khhD8uXKDY5O4CZC/+nSQw==; Original-Received: from [87.69.77.57] (port=2893 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZNl-0007qs-UP; Sun, 07 Aug 2022 02:03:26 -0400 In-Reply-To: (message from Alan Mackenzie on Sat, 6 Aug 2022 20:13:13 +0000) 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:293175 Archived-At: > Date: Sat, 6 Aug 2022 20:13:13 +0000 > From: Alan Mackenzie > > Narrowing is primarily a user feature. Users can arbitrarily narrow a > buffer to ANY contiguous region of text. This feature doesn't interfere with user-level narrowing. > So when a major mode needs to examine text even slightly distant > from point, it MUST widen No, it doesn't. It shouldn't. If the buffer is narrowed, the portions outside the narrowing don't exist, period. That's how most of Emacs behaves, starting from display and ending with navigation and search commands. With display, for example, narrowing a buffer in a certain way can completely disrupt how bidirectional text is shown, and yet we intentionally do nothing to avoid that. Neither should any major mode. A mode is not exempt from obeying the narrowing. It cannot claim that it "knows better". If some features of the mode work in suboptimal fashion in the presence of narrowing, the mode has no business "fixing" that -- it's what whoever did the narrowing wanted, so that is what they should get. > Also, in font locking, a major mode might need to examine text > arbitrarily far from the fontification region. It shouldn't. The Emacs display code specifically asks the mode to fontify only a relatively small chunk of text, and it does so for a very good reason: performance, especially in large buffers. That CC Mode unilaterally decided not to be bound by these consideration is IMNSHO a very unfortunate decision, to say the least, that causes us and me personally (as someone who works on C and C++ code a lot) a lot of grief. Editing C/C++ code is lamentably becoming more and more slow and sluggish with each new Emacs release, even on moderately fast machines. Significantly, it doesn't become more stable, as bugs keep being reported. As I've said many times, if this is the direction you think CC Mode should be developed, I'd prefer less accurate fontification that would give us simpler, faster, less buggy, and more easily maintained code. My hope is that tree-sitter integration will perhaps solve this for good, because frankly, I'm sorry to say that I've lost all hope that CC Mode by itself will ever be fixed to perform better. > For example, to know whether or not a particular place is inside a > comment or a string, or to know whether to fontify a string opener > with f-l-warning-face (when the string is unterminated) or > f-l-string-face (for a validly terminated string). If a string begins outside of the narrowing, it is not a string, period. > There's no "weren't supposed to do" involved anywhere. Major modes, > like all Emacs Lisp programs, have, by design, access to the full range > of Emacs's facilities. No, they don't, they shouldn't. You have it backwards: the design of Emacs in the presence of narrowing is to behave as if the text outside of the restriction didn't exist. > I've recently spent many hours reading the discussion for bug #56682 and > its predecessor bug, and if I recall correctly, you have put the > `widen'/ `narrow-to-region' "bug" into other hooks called from > redisplay. If I'm right, there, was there any specific reason for this? > Like, did it dramatically speed anything up (and I'm not talking about a > mere 10%, say, here)? The speedups are dramatic. You can easily try that yourself; the recipe for doing that was described here many times. > Several times in the thread when other posters have complained about the > new long lines facility, you have invited them to "set > long-line-threshold to nil". That doesn't allow them to use the other > benefits of the facility whilst retaining fully functional `widen', > 'narrow-to-region' and font-locking. Would it be possible, please, to > add an option to enable such a mix of features? Which "facility" are you talking about, specifically? The changes related to long lines involve locked narrowing in several places; they don't involve anything else.