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: Major modes using `widen' is a good, even essential, programming practice. Date: Sat, 6 Aug 2022 20:13:13 +0000 Message-ID: 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="11684"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org, Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 06 22:14:09 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 1oKQBU-0002uP-F8 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Aug 2022 22:14:08 +0200 Original-Received: from localhost ([::1]:45210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKQBT-0007xy-21 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Aug 2022 16:14:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKQAv-0007I3-G3 for emacs-devel@gnu.org; Sat, 06 Aug 2022 16:13:33 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:56507 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oKQAt-0005ps-DF for emacs-devel@gnu.org; Sat, 06 Aug 2022 16:13:33 -0400 Original-Received: (qmail 47680 invoked by uid 3782); 6 Aug 2022 20:13:15 -0000 Original-Received: from acm.muc.de (p2e5d57a4.dip0.t-ipconnect.de [46.93.87.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 06 Aug 2022 22:13:15 +0200 Original-Received: (qmail 8300 invoked by uid 1000); 6 Aug 2022 20:13:13 -0000 Content-Disposition: inline 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:293154 Archived-At: Hello, Emacs, hello, Gregory. In the thread for bug #56682 "Fix the long lines font locking related slowdowns" on Wednesday 2022-08-03 09:04:03 +0000, you (Gregory) posted this: > .... based on the observation that half of the programming language > modes in core do use widen, which they weren't supposed to do. You are entirely wrong there, and I suspect you personally don't use narrowing (as a user), so don't really understand it. Narrowing is primarily a user feature. Users can arbitrarily narrow a buffer to ANY contiguous region of text. So when a major mode needs to examine text even slightly distant from point, it MUST widen, to be sure that the text to be examined is within the visible region. Also, in font locking, a major mode might need to examine text arbitrarily far from the fontification region. 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). 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. 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'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)? Otherwise, this will just make programs fail for no good reason. If I'm right about this, could you please restore those hooks to full functionality by removing the "bug" from them. 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? Thanks! -- Alan Mackenzie (Nuremberg, Germany).