From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Tue, 19 Jul 2022 10:21:00 +0200 Message-ID: References: <38c1a31040d2d2bc47ae@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1529"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: 56393@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 19 10:22:49 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 1oDiVD-0000Bo-JL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 10:22:47 +0200 Original-Received: from localhost ([::1]:39590 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDiVC-0001C0-DP for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 04:22:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56694) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDiUU-0000pi-Jv for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54976) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDiUU-0006If-BI for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDiUT-0000I2-TI for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 04:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jul 2022 08:22: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.16582188711053 (code B ref 56393); Tue, 19 Jul 2022 08:22:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 19 Jul 2022 08:21:11 +0000 Original-Received: from localhost ([127.0.0.1]:52735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDiTf-0000Gv-8S for submit@debbugs.gnu.org; Tue, 19 Jul 2022 04:21:11 -0400 Original-Received: from mail-ej1-f51.google.com ([209.85.218.51]:45856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDiTc-0000Gh-Cg for 56393@debbugs.gnu.org; Tue, 19 Jul 2022 04:21:09 -0400 Original-Received: by mail-ej1-f51.google.com with SMTP id fy29so24597194ejc.12 for <56393@debbugs.gnu.org>; Tue, 19 Jul 2022 01:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=3K3dimCWKFPVfii8BgxUv/QO7DQc0TpAjHwXWneqWDM=; b=QnuhP3RqDY1NmhPG0EQgANzuWwI7GfGoU7FFqbrTUeOQmHjSW3hsvgDOqA3cOkntVX PE3FETDcd4MlCV2o1W2zquLDWEuSsFkALHyKIvbLBTDePC6Sm6TKsww2J1iuYPjD/sQc 5RjJF4Ug11W8a2lT1qI6GXfpV8FbpsIQDZxNKMwkNVj7g8qTLUNGSIqjW7XsJOKygIUW CmayCubECU6crJob4WHoNR1lho2VFZLWr8KIrAqA+pw4oIggnSV13Ypd2dSit2ThDbB8 o+L4SsPG6AQ+qmsXMeMSsx+IIbaQBsL6O7kVPV3m0tuef6JqKOhp+uCWjW1t8bdYa8ns EFxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version:content-transfer-encoding; bh=3K3dimCWKFPVfii8BgxUv/QO7DQc0TpAjHwXWneqWDM=; b=GoQMZZp9ztQob8uyM5Q8suzaqo9julPebMVaxnh13MEbtgDZEi3J6Yzrn2ATwG4E7s UHW/FsJmDEkrZFm7Zi8Zkc4Eq3X+xC+3jv6MhOC+jCSjVM6Slyfpb5s/LJUjUW/MeOpX Hy7lWc0QN/l6pEG8ZtSlRTqe7Vhr2yhcAZH0MFVnd7gqe8zKwqfFMWHH1qS3JPQyLGS9 bVmLThO4iCnY+WwL5n0vFfmUCE8Z+7K2jSlE6tRLGwqvljCaLwvRI7bajcj3xV3iMOvw 2AuEcG3zRjoJjJE672WHPaYrE/yb5BiAubbsYzoZEHLisuKTfM8Ibt2Vm/UhOLZmLf0+ 792A== X-Gm-Message-State: AJIora9deKAd+MARWwIO3gFy4aYJhRk0X3MDLfkqn0nb84j3Jdxx8zu4 SVmrWPI6IrHKbjPo5SRG1WNntREw3wI= X-Google-Smtp-Source: AGRyM1t1fUI8katTCjsjqr/QI+1WiPyP+mbwLrC49OrfJSFOfa7+laO7LUyS5QacnMx1tjSeSW5pIA== X-Received: by 2002:a17:906:ef8c:b0:72c:780c:6693 with SMTP id ze12-20020a170906ef8c00b0072c780c6693mr27914465ejb.196.1658218861969; Tue, 19 Jul 2022 01:21:01 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e36437.dip0.t-ipconnect.de. [217.227.100.55]) by smtp.gmail.com with ESMTPSA id g23-20020a170906539700b006fef0c7072esm6512788ejo.144.2022.07.19.01.21.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 01:21:01 -0700 (PDT) In-Reply-To: (Gregory Heytings's message of "Mon, 18 Jul 2022 10:49:44 +0000") 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:237409 Archived-At: Gregory Heytings writes: >> That's only ~100 lines of code?=C2=A0 Can that be? I'm suspecting that I >> don't use Magit right, again.=C2=A0 Or something. >> > > You're using Magit right: it's indeed a small fix. > > Your comments would be most welcome, of course. First of all - I find your design idea really nice. I think the iterator layer, if you will, is the right place for this kind of functionality. Whatever. Let me distinguish your code into the part that decides whether to do something, and the part that then does it. I'm currently only thinking about the first part, the determination if to do something. What I see, please correct me if I'm wrong: The determination is part of what I call Emacs' redisplay layer. Rediplay_window sets buffer's long_lines_optimization_p flag to true, under some condition. (l_l_o_p flag is then used to let the iterator layer do something, later.) Mark_window_display_accurate computes unchanged_size as Z - BEG, which is the buffer's size at that point. m_w_d_a is called from redisplay_internal, again under certain conditions, basically when a thorough display has been completed successfully. Questions I'm pondering are, and I'm not saying anything is wrong or something, I'm just thinking about this, and I guess you have been thinking about the subject longer than I have - 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? - 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? - 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) <=3D 1) Does the last line mean "buffer got smaller"? Sorry if I'm dense here, but I don't get it.