From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Sat, 06 Aug 2022 17:05:24 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8828"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Gregory Heytings To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 06 23:06:15 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 1oKQzu-00023o-IB for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Aug 2022 23:06:14 +0200 Original-Received: from localhost ([::1]:60912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKQzt-0003Bd-Ix for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Aug 2022 17:06:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKQzF-0002LA-40 for emacs-devel@gnu.org; Sat, 06 Aug 2022 17:05:33 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKQzC-0004Cv-Fx for emacs-devel@gnu.org; Sat, 06 Aug 2022 17:05:32 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EB3758079C; Sat, 6 Aug 2022 17:05:28 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D20838076F; Sat, 6 Aug 2022 17:05:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659819927; bh=zdifKinhDkI9ixJrbApP4MEI1erWFsvAHpeh4suegdI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MQtVE2zgPaOypnkQhJSizg5TJexzeI093zrR5Wk8EFUv4/W0n65CBMQ8BY0yAzNzd nWnvNyHAOhVJMsoUb1uzuJ8Z1mkdYm73h3/aJ/S8sfCF30CQ6MceIMeSMaXCnsX/nO AGhsxvww3xqFfMtL5mkN/wW7mqoJm/ihRHZNS69jxNDmyNm+XIG/B0Z85qsXlOV6EN eAiUeLxaHU2Z6V1m+LzpKvxa+0Sm6s/nuM7U7htjVBjAqraKMw0gjJ99s8TckWSCXM mJyaDWz5wX/Pqi4FaJ4TMFo8/tf5LxmtGsWIMlnGP5BWo4+XDQ/yHUKTqbhkX4FDip VJY4LMkgfENvw== Original-Received: from milanesa (unknown [46.44.221.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0CBC512030C; Sat, 6 Aug 2022 17:05:26 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sat, 6 Aug 2022 20:13:13 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:293157 Archived-At: > 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. Agreed. > Also, in font locking, a major mode might need to examine text > arbitrarily far from the fontification region. Agreed. But the two cases are quite different: the font-lock case goes through font-lock, which knows very well that the whole buffer is needed, so *it* widens, making it unnecessary for the major mode to do so. The same holds for `indent-line-function` where the generic code widens before calling that function. In both cases, it's then very important that the major mode does not redundantly widen on its own because it's not just redundant but it breaks those cases where widening is wrong (most commonly because of something like MMM-mode). So, yes, calling widen is normal for a command provided by a major mode. But it's almost always a bug for a major mode function called by font-lock or by the indentation code. Stefan