bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are


From: Eli Zaretskii
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

> Cc: 56683@debbugs.gnu.org
> Date: Thu, 21 Jul 2022 19:45:19 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> > 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.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]