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: locked narrowing in ELisp Date: Tue, 16 Aug 2022 16:18:04 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21054"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 16 22:19:16 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 1oO31v-0005IA-U3 for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 22:19:16 +0200 Original-Received: from localhost ([::1]:47478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO31u-0001KQ-Iy for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 16:19:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO30t-0000dv-OB for emacs-devel@gnu.org; Tue, 16 Aug 2022 16:18:12 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55766) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO30q-0001nD-Jp for emacs-devel@gnu.org; Tue, 16 Aug 2022 16:18:10 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E8721441594; Tue, 16 Aug 2022 16:18:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 368D7441592; Tue, 16 Aug 2022 16:18:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660681085; bh=izLQ1EZJ/PdmZJSh6HsUvDDkI6n7EGvHJ386n13SCns=; h=From:To:Subject:Date:From; b=VfRQkoplIcQgKgcDnXs9RTRaCbPpEexfSlKDMdR6/7f4TcTZk0SZLGsCYSTqBJAyr XOHRNbKUATDpJBi3a26HIdcqg5W40ebK0IGtl8ZiplTAWEwY8wSdoZ5xE+AkKaHMLx V7NCa5tGxGXrd3nxnilavkeTe2jWFhfG+tFQRzLxFvNTREyFbYvjJyZ9Dii10W7yqB dGJoHj9yV95/KrxlBJwnyfF+5PuSQQt3KD+eS3GjL+z6Xhr8zvDxgnrVXWVDXkLIiO 4KpiaiFygIVvstFFaXD6Sad3cnokpDWR7DuJwC1Z8CBcVybJMzMGkUHsGoPITVoS+y FGFWUSpOpGnMA== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 08DCD1202E6; Tue, 16 Aug 2022 16:18:04 -0400 (EDT) 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:293518 Archived-At: The new "fast long-lines" code uses a "locked narrowing" to try and avoid being defeated by naive font-lock (and other) code. This is a good heuristic to try and make sure Emacs stays responsive even in the presence of naive packages not designed for such long lines. Beside the need to override this in those rare packages where we can provide better behavior with careful coding, the new code also lacks a way to install such a locked narrowing from ELisp, even though it seems only natural to use similar heuristics from ELisp code (e.g. when jit-lock is run from a timer). But as pointed out by Lars, this is related to the old discussion about "classifying" narrowing, so as to distinguish narrowings installed by the user via `C-x n n` from those installed by packages like MMM-mode or Info-mode (or nowadays those installed by the redisplay). These distinctions are important because various code may need to look "outside" of those narrowings in some circumstances, but which "outside" to use depends on the particular situation. We've discussed it in the past and I still don't know what would be a good API, but one particular class of `widen` which is known to be used within narrowings that should *not* be overridden is those `widen` calls used in "parsers" that try to understand the context of an operation. Those `widen` will sometimes be used in circumstances where they may actually want to *narrow* rather than widen (e.g. the narrowing might be needed to make sure the parser only looks at the part of the buffer that it can understand (e.g. in MMM-mode), or it might be needed in order to avoid the risk of spending an eternity parsing GBs of text (at the cost of misparsing in too-large buffers)). Last time we discussed these issues, we ended up deciding that indentation (like font-lock before it) should "eagerly widen" (i.e. undo any user-setup narrowing) before calling the mode-specific code. This way, the indentation and font-lock code of a major mode should simply never need to call `widen` and things like the MMM-mode (or the long-lines code in redisplay) can just setup the narrowing before calling that major mode code without any need to "label" the narrowing. This was an elegant solution, but it seems to be too limited, because the parsing code that want(ed) to `widen` is typically also called from other parts of the major mode than the indentation or font-lock code. In the past, we played with having a new widening function (there was a `prog-widen` briefly in `prog-mode.el`). Maybe we should (re)introduce such a thing (or maybe an optional arg to `widen` which would indicate what "kind" of widening we want to do), coupled with some kind of `widen-function` which MMM-mode and the redisplay could setup to filter/tweak those widening. Within an MMM-mode or "redisplay locked narrowing", we *generally* want `widen` not to widen past the limits imposed by MMM or by the redisplay, but there will be cases where we do want to allow it (e.g. in `nlinum-mode` the widening will usually want to be allowed to override those narrowings in order to compute the right line number), so we clearly not all calls to `widen` are the same. Stefan