From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Fri, 02 Dec 2022 09:10:26 -0500 Message-ID: References: <6e305c9b-7702-133a-3347-f64db05ade3f@yandex.ru> <83mt89kt10.fsf@gnu.org> <834juglesn.fsf@gnu.org> <83r0xkjw5s.fsf@gnu.org> <83pmd3ioxx.fsf@gnu.org> <47153506021498df087c@heytings.org> <83bkomhlmn.fsf@gnu.org> <4715350602cf2ec6860b@heytings.org> <83a646hkat.fsf@gnu.org> <47153506028bbb3bc8b3@heytings.org> <47153506021115866615@heytings.org> <20f32a53dc3f5fbc5b65@heytings.org> <83359ygrje.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6863"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 56682@debbugs.gnu.org, gregory@heytings.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 02 15:11:16 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p16l1-0001d5-DI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Dec 2022 15:11:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p16kr-0000wG-TA; Fri, 02 Dec 2022 09:11:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p16kp-0000vd-CN for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 09:11:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p16kp-0003fU-3i for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 09:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p16ko-0005uL-V4 for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 09:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Dec 2022 14:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.166999023822681 (code B ref 56682); Fri, 02 Dec 2022 14:11:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Dec 2022 14:10:38 +0000 Original-Received: from localhost ([127.0.0.1]:46949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p16kQ-0005tl-4c for submit@debbugs.gnu.org; Fri, 02 Dec 2022 09:10:38 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p16kM-0005te-Ve for 56682@debbugs.gnu.org; Fri, 02 Dec 2022 09:10:37 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4F9D5100126; Fri, 2 Dec 2022 09:10:29 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AB808100134; Fri, 2 Dec 2022 09:10:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1669990227; bh=Whypa3cBassZGG3DJDyVZupqF75qu4QTJDBhBBJTErI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=g14UWBkqk7vUAusnrre/2OQr3MqYfV2Ymn6/8kWcCehBI82ZSSWiw63mMHq7b3lif g89iS6yYUs7fIFKSE616jQol+uww8cZwIQfEMgyCS0M0yBAra+LKabEZv6HBtDYlXF 1NGmc6kG69pmpmWnpZeAucwEbe4aWqWIYCO83CSJF5LM5vln5ywD2wyHyZIcWlkjyN A5BBapPOHRrW3yTJV/jz/IzQ+ltSV+qKhBfX/zO3scA4X3ofIjRCarcDl5nIBbvkyF 2u34Fi/IQGbfcNc3VGKG5ZKVycCqwdMtY5Ong/Y8B2eNsQFdWsbCT1ybEryvGap/8T rRWHEak7V/94g== Original-Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68A07122AB3; Fri, 2 Dec 2022 09:10:27 -0500 (EST) In-Reply-To: <83359ygrje.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Dec 2022 10:04:37 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249747 Archived-At: >> My suggestion was to have as "steady state" that "everything is scanned >> except for a region between BEG...END and no line was found to be larger >> than MAX_SEEN_LINE_LENGTH". So it requires keeping track of a BEG..END >> (BEG can be an integer but END would likely be an (insert-before) >> marker) plus an integer keeping track of MAX_SEEN_LINE_LENGTH. >> Initially BEG is 1 and END is Z. > > I don't understand how you keep track of BEG and END, in general. Every buffer modification updates it. > E.g., deletion of a single character can in some cases reset BEG to > 1 and END to Z, right? No, why would you think so? Any change at position POS would set BEG to (min BEG POS) and END to (max END POS) (modulo marker-position updates for END). I now realize that a deletion can increase line length by removing LF chars, so the condition I proposed to decide when a rescan is needed would need to be adjusted, but the basic idea still stands. >> I can't think of a good way to detect when MAX_SEEN_LINE_LENGTH can be >> made smaller, tho, so we might still need to rescan the whole buffer >> every once in a blue moon. > That, too, is a complication. For the 99% of the buffers the MAX_SEEN_LINE_LENGTH should stay small "for ever" so it's probably not a big issue. > Once again, there's absolutely no reason to scan more than a limited > region around point where redisplay is likely to look. Indeed, that's another possible approach. > Scanning the entire buffer is a waste, and can potentially degrade > performance in very large buffers without any long lines. The full-buffer scan would only be needed once when inserting the file into the buffer, so it's not clear it would degrade performance in any significant way, but if needed we can make it more lazy by keeping track (in addition to the "beg..end of not yet scanned changes") of the "beg..end of region already scanned" so we only scan the part of the buffer actually visited (which will still degenerate to "the whole buffer" if we display BOB and then EOB, of course, as usual). Stefan