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#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated Date: Fri, 22 Jul 2022 09:30:28 +0300 Message-ID: <83wnc5lkvv.fsf@gnu.org> References: <87h73ab8bo.fsf@gmail.com> 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="28843"; mail-complaints-to="usenet@ciao.gmane.io" Cc: andreyorst@gmail.com, 56683@debbugs.gnu.org To: Gregory Heytings , Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 22 08:31: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 1oEmCQ-0007Gr-Ve for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Jul 2022 08:31:47 +0200 Original-Received: from localhost ([::1]:56200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEmCP-0006Kk-Ew for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Jul 2022 02:31:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEmBi-0006IE-VW for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 02:31:10 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEmBi-0007xo-JW for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 02:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEmBi-0004Jt-BJ for bug-gnu-emacs@gnu.org; Fri, 22 Jul 2022 02:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jul 2022 06:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56683 X-GNU-PR-Package: emacs Original-Received: via spool by 56683-submit@debbugs.gnu.org id=B56683.165847144916582 (code B ref 56683); Fri, 22 Jul 2022 06:31:02 +0000 Original-Received: (at 56683) by debbugs.gnu.org; 22 Jul 2022 06:30:49 +0000 Original-Received: from localhost ([127.0.0.1]:39909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEmBT-0004JN-MM for submit@debbugs.gnu.org; Fri, 22 Jul 2022 02:30:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEmBN-0004J3-Nj for 56683@debbugs.gnu.org; Fri, 22 Jul 2022 02:30:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEmBI-0007jX-8v; Fri, 22 Jul 2022 02:30:36 -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=l44QvWwLBDPV7DFMDpf/WnsRKtn+nbMTIxYDsoKX2/Q=; b=qzv5IbY7sNx7NoaDnfUj JFvv0CqH7DUidEDg8p1hnb3RidNfOF4OT07xK9qBpvg7GBuEBZ2+k0M4GHSZmPe1k18fml1U/yekI hJZ7R4o/PuvENfk5lEBt5d/Pxl8w5DAZe3KH0FTyG9fpaozHTzikvO5GqyVYwaU1z7SGutXEAdz92 8vnZddZHteOXyh460aYeTdXa7kdmXwpMLOpFLJPqNmFhMv4CLgXpIkYP5VErIm+w9Npg1534G6kw+ 3bJJ4gC3RaR6vSTlTdFFWrg/IEjersrG35xSbp4Tii0uwEySlYzcR0JOb4Zyzmr21Q38srLECtozH q+dbdX4Bptb3vg==; Original-Received: from [87.69.77.57] (port=1308 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 1oEmBG-0006ll-KX; Fri, 22 Jul 2022 02:30:35 -0400 In-Reply-To: (message from Gregory Heytings on Thu, 21 Jul 2022 19:45:19 +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:237589 Archived-At: > Cc: 56683@debbugs.gnu.org > Date: Thu, 21 Jul 2022 19:45:19 +0000 > From: Gregory Heytings > > > As a side question, does these optimizations work with truncated lines? > > As far as I can tell Emacs is not as responsive as when the lines are > > wrapped, but I don't know how to measure this precisely. > > They do work with truncated lines, but I suspect that truncated lines > require specific fixes to work efficiently. I think we should take look at this fragment from hscroll_window_tree: /* Move iterator to pt starting at cursor_row->start in a line with infinite width. */ init_to_row_start (&it, w, cursor_row); if (hscl) it.first_visible_x = window_hscroll_limited (w, it.f) * FRAME_COLUMN_WIDTH (it.f); it.last_visible_x = DISP_INFINITY; move_it_in_display_line_to (&it, pt, -1, MOVE_TO_POS); /* If the line ends in an overlay string with a newline, we might infloop, because displaying the window will want to put the cursor after the overlay, i.e. at X coordinate of zero on the next screen line. So we use the buffer position prior to the overlay string instead. */ if (it.method == GET_FROM_STRING && pt > 1) { init_to_row_start (&it, w, cursor_row); if (hscl) it.first_visible_x = (window_hscroll_limited (w, it.f) * FRAME_COLUMN_WIDTH (it.f)); move_it_in_display_line_to (&it, pt - 1, -1, MOVE_TO_POS); } Specifically, init_to_row_start can potentially start from a very far away buffer position, especially in buffers with a single long line, and AFAICT the subroutines called by init_to_row_start aren't restricted to the "narrowing" for long lines, so they go to BOB in this case. The problem here is that this code handles automatic hscrolling, so any changes to it need to be careful not to destroy the use case of moving point horizontally to a position that is beyond the right or left window edge (which is what auto-hscroll is for). Alternatively, maybe automatic hscrolling should be disabled in such buffers (or we should advise that), and then we should have convenient commands to hscroll manually so as to bring point into the view. (Maybe we even have such commands already, I don't know.)