From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Sat, 09 Jul 2022 09:20:30 +0300 Message-ID: <83tu7q3iz5.fsf@gnu.org> References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <83a69n90t8.fsf@gnu.org> <38c1a31040ad21b41adc@heytings.org> <835ykb8x3z.fsf@gnu.org> <38c1a310403dbabc7270@heytings.org> <834jzv8sv4.fsf@gnu.org> <38c1a31040ba2976eb4d@heytings.org> <83y1x77c2w.fsf@gnu.org> <87k08rkvgb.fsf@gnus.org> <38c1a31040e94458bd3d@heytings.org> <83o7y277b8.fsf@gnu.org> <762d224809bcab0d6bbc@heytings.org> <83fsje74pz.fsf@gnu.org> <762d224809bc038d2030@heytings.org> <838rp672p7.fsf@gnu.org> <762d224809114fbaf4af@heytings.org> <834jzu6wnu.fsf@gnu.org> <762d224809c7a439895e@heytings.org> <83wncq5dvu.fsf@gnu.org> <3ffab1919622ce555e12@heytings.org> <83ilo95uz8.fsf@gnu.org> <3ffab19196bc0451adb6@heytings.org> <83edyx5j2u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7203"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, Gerd =?UTF-8?Q?M=C3=B6llmann?=" , 56393@debbugs.gnu.org To: gregory@heytings.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 09 08:21:27 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 1oA3qI-0001fs-PW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Jul 2022 08:21:26 +0200 Original-Received: from localhost ([::1]:46160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oA3qH-0003F4-CF for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Jul 2022 02:21:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44594) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oA3pv-0003Ev-8F for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2022 02:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39741) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oA3pt-0004YS-TT for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2022 02:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oA3pt-0002pL-Jx for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2022 02:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Jul 2022 06:21: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.165734763810828 (code B ref 56393); Sat, 09 Jul 2022 06:21:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 9 Jul 2022 06:20:38 +0000 Original-Received: from localhost ([127.0.0.1]:33638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oA3pV-0002oa-W1 for submit@debbugs.gnu.org; Sat, 09 Jul 2022 02:20:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oA3pU-0002oO-58 for 56393@debbugs.gnu.org; Sat, 09 Jul 2022 02:20:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oA3pO-0004WD-Bf; Sat, 09 Jul 2022 02:20:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=bbf0NyirbvVquEb8IPPo8BFcAeRvt3DgbDJtTCsQ+eA=; b=Zz82yTJkIYcvhlWRQyNK KS8shLiW/KHx12BmNR/+EYmP9UXi6WlrgEv7wXMDQ7VNLDykRjxpok6b9sCp7PP+wb981MzMbz0Tf MkQifVKPvTo6T/2Rv2mMKWVbxcNAAug683f5qP9jaGv/4CpXoAugYT1l8nVRIjoVMH7IctsOlJicB sr4AcZSP6k+4G6nW9bzeU/MMEY2YtcUYA9PcsY4xJ0Mh+oXxdiUwCFkZio847XMWABL+aIIc1Ohuk fMREgouKGaiRmHqo6UcdxHbBttssctwd340/dkrne49lwVUNN8s+SJhMistAs0krNbtp2gx+k3CtW ODeEWWMAgsFwSw==; Original-Received: from [87.69.77.57] (port=3287 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oA3pN-0002IB-R3; Sat, 09 Jul 2022 02:20:30 -0400 In-Reply-To: <83edyx5j2u.fsf@gnu.org> (message from Eli Zaretskii on Thu, 07 Jul 2022 13:10:49 +0300) 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:236475 Archived-At: > Cc: larsi@gnus.org, 56393@debbugs.gnu.org > Date: Thu, 07 Jul 2022 13:10:49 +0300 > From: Eli Zaretskii > > I don't yet have a good idea about where to check whether "narrowing" > is necessary for commands like C-n and C-v, but maybe look where I set > the display_working_on_window_p flag as guideline. Another idea would > be to use those new members in 'struct window', but then (a) it is > less clear when to reset them, and (b) some commands might go far > away, thus making those values no longer pertinent. After some more thinking about this, I think I do now have an idea how to tackle command that employ the display code. I see that you decided to produce the "restriction" in init_iterator, which would, of course, work, but IMO it has a disadvantage: init_iterator is called a lot, so computing the "restriction" in it should be very fast. Your current implementation _is_ fast, but AFAIU its result is that we _always_ restrict the display code from seeing the entire buffer, even if there are no long lines in it, which I think is unnecessary. The original implementation only did that when it detected a long line, and I think we should keep it that way, because the "restriction" will inevitably have some negative effects, however minor, on what we display. My proposal is to calculate the "restriction" in start_display. That function is called by all the commands/functions that use the display code outside of redisplay proper. (I think one or two such places call init_iterator directly, but we can either handle them specially or change them to use start_display.) In addition, to prevent even start_display doing more than necessary, redisplay_window should compute the restriction for the window that is about to be redisplayed, and store the values in 'struct window'; then init_iterator, if called inside redisplay, will then simply reuse those values, and start_display will refrain from computing them anew. (To know whether some code is invoked by redisplay, test the value of the global variable redisplaying_p.) This way, we could make the "restriction" smarter, and only apply it when needed. Another advantage is that this way the "restriction" will be the same for all the code that is called by redisplay_window, directly or indirectly, which I think is safer than having different "restrictions" computed by different functions.