From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Tue, 19 Jul 2022 08:53:12 +0000 Message-ID: References: <38c1a31040d2d2bc47ae@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39078"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56393@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 19 10:54:23 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 1oDizm-0009sx-Ho for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 10:54:22 +0200 Original-Received: from localhost ([::1]:55018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDizl-0005EF-B4 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 04:54:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDizS-0005E1-1c for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55008) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDizR-0002nq-P9 for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:54:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDizR-0003HT-M1 for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jul 2022 08:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165822079712540 (code B ref 56393); Tue, 19 Jul 2022 08:54:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 19 Jul 2022 08:53:17 +0000 Original-Received: from localhost ([127.0.0.1]:52764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDiyj-0003GB-2a for submit@debbugs.gnu.org; Tue, 19 Jul 2022 04:53:17 -0400 Original-Received: from heytings.org ([95.142.160.155]:43658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDiyg-0003G0-Dq for 56393@debbugs.gnu.org; Tue, 19 Jul 2022 04:53:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1658220793; bh=byv2xxPg49jYqwGGim4we8zdCPq01amQQ+L7IJAaXqk=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=C5Uxn87lf0BOXZmcRIRjhd4w+X5fmeAYDPNdL8SB8ngySwdlNWzOMluUlUSQ798cd /I/+NilxNWNjWtXqptwdHFrHgOgKe5r4+EfukoWmoKEUmMZGoac2BR1hB1x2TvfCCW dWHldvZqtbXXFmfL17ciV/2g1syApdn7Opc1Eb5fLCDodBTKZoPc1FRN/0uDU+SLgw sRZqtTf03MHmU9fwpeakIfFjdU/OwmcF6qIadTOl36vADwjrbA8oGsFZBn42XKvnmO L3Nim2eRgKx8rRc+2sMykBE6tJiBMjJ2DF4yI79nN777d17QEGW5S+t9mJPZO+HKzr ziijVF1NlfkvQ== In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:237410 Archived-At: Thanks again for your detailed comments! > > - Since the determination is done in what I'd call redisplay, what if a > buffer with long lines is never, or not yet, displayed? Are there > circumstances under which we are using an iterator then? Background > fontification? Some hook? Other stuff I don't know about? Could that > cause us trouble? > If a buffer with long lines is never or not yet displayed, the specific optimizations do not take place. That was a very important if not critical improvement, because Emacs may internally use buffers with long lines, and they should be entirely unaffected by that change. (For example, the newsrc.eld file used internally by Gnus contains one such long line; if the same temporary restrictions were used in that buffer, it is possible that Gnus would not work correctly anymore.) As far as I can tell, iterators are used in such buffers, too, but they are not fontified. Fontification happens only when necessary, that is, when the buffer is actually displayed. > > - I did not see that l_l_o_p is set to false anywhere. Should it be? > What if a buffer is modified in such a way that there are no long lines > anymore? > Gosh! That was an error, thanks! > > - I don't understand this in redisplay_window: > > /* Check whether the buffer to be displayed contains long lines. */ > if (!NILP (Vlong_line_threshold) > && !current_buffer->long_line_optimizations_p > && Z - BEG - BUF_UNCHANGED_SIZE (current_buffer) <= 1) > > Does the last line mean "buffer got smaller"? Sorry if I'm dense here, > but I don't get it. > It is (- (point-max) (point-min) (buffer-size-after-last-redisplay)), so it means "the buffer got larger by more than one character". (Note that (buffer-size-after-last-redisplay) is a fictional function.) But after discussing this with Eli I'm not convinced that it's a good enough heuristic. The previous heuristic was simply "the buffer contents have changed", and I wanted to refine it a bit.