bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

Eli Zaretskii
> Cc: [hidden email]
> From: [hidden email]
> Date: Mon, 08 Feb 2021 03:54:32 +0900
>
> I only want auto-hscroll-mode to scroll buffer automatically.

It does, when you give it enough information that it should.  When
your input focus is in another window (the mini-window in the case of
C-s), I think it would be strange for Emacs to auto-scroll some other
window.

> If a searched string is not displayed in the window, I might think the
> searched string does not exist in the buffer.

The searched string _is_ displayed, when you first find it.

> If an image is hidden, I might think the image is a solid color same as
> the emacs background color.

Just move the cursor and you will see it.

Sorry, I see no problem here, certainly not something that would
justify complicated triggers for redisplaying a window.



Reply | Threaded
Open this post in threaded view
|

bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

ynyaaa
Eli Zaretskii <[hidden email]> writes:

>> Cc: [hidden email]
>> From: [hidden email]
>> Date: Mon, 08 Feb 2021 03:54:32 +0900
>>
>> I only want auto-hscroll-mode to scroll buffer automatically.
>
> It does, when you give it enough information that it should.  When
> your input focus is in another window (the mini-window in the case of
> C-s), I think it would be strange for Emacs to auto-scroll some other
> window.
>
>> If a searched string is not displayed in the window, I might think the
>> searched string does not exist in the buffer.
>
> The searched string _is_ displayed, when you first find it.
>
>> If an image is hidden, I might think the image is a solid color same as
>> the emacs background color.
>
> Just move the cursor and you will see it.
>
> Sorry, I see no problem here, certainly not something that would
> justify complicated triggers for redisplaying a window.

I investigated some more.

#'isearch-update tries to control the hsrcoll using
#'pos-visible-in-window-group-p.
Under the folloing conditions, it returns coordinates as if the point is
at the beginning of a virtual next line.
  (1) the point is the end of the buffer.
  (2) the buffer does not end with a newline.
  (3) the last line is displayed in the window.
  (4) the last line is truncated.
So the calculation is wrong and the hscroll becomes inappropriate.

With a different reason, if isearch started with a large hscroll and the
last match is near the beginning of a line, the hscroll becomes
inapropriate.
For example, evaluate the form below, and type 'C-s a C-s', then the
current point is hidden to the left of the window.
This is because #'isearch-update only checks whether the point is to the
right of the window and does not check whether the point is to the left
of the window.

(let ((buf (generate-new-buffer "tmp")))
  (switch-to-buffer buf)
  (setq truncate-lines t)
  (insert-char ?x 100)
  (save-excursion
    (insert-char ?\n 100)
    (insert ?a)))

Regarding image-mode, a simpler example of the bug is written as below.
The hscroll does not change when the buffer is changed.
Image display, window focus or message is not related.

(let ((buf (generate-new-buffer "tmp")))
  (switch-to-buffer buf)
  (setq truncate-lines t)
  (dotimes (i 200)
    (insert (format ":%03d" i))
    (when (= 0 (% (1+ i) 100)) (insert ?\n)))
  (forward-char -1)
  (sit-for 1)
  (set-window-hscroll nil (window-hscroll))
  (save-excursion
    (forward-char -100)
    (insert-char ?\n 10)
    ))



Reply | Threaded
Open this post in threaded view
|

bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

Eli Zaretskii
> Cc: [hidden email]
> From: [hidden email]
> Date: Sat, 13 Feb 2021 00:41:18 +0900
>
> #'isearch-update tries to control the hsrcoll using
> #'pos-visible-in-window-group-p.
> Under the folloing conditions, it returns coordinates as if the point is
> at the beginning of a virtual next line.
>   (1) the point is the end of the buffer.
>   (2) the buffer does not end with a newline.
>   (3) the last line is displayed in the window.
>   (4) the last line is truncated.
> So the calculation is wrong and the hscroll becomes inappropriate.

Thanks, I wasn't aware isearch called pos-visible-in-window-p.

I fixed pos-visible-in-window-p on the master branch in this case, so
this part of the report now works correctly.

> With a different reason, if isearch started with a large hscroll and the
> last match is near the beginning of a line, the hscroll becomes
> inapropriate.
> For example, evaluate the form below, and type 'C-s a C-s', then the
> current point is hidden to the left of the window.
> This is because #'isearch-update only checks whether the point is to the
> right of the window and does not check whether the point is to the left
> of the window.
>
> (let ((buf (generate-new-buffer "tmp")))
>   (switch-to-buffer buf)
>   (setq truncate-lines t)
>   (insert-char ?x 100)
>   (save-excursion
>     (insert-char ?\n 100)
>     (insert ?a)))

This now also works correctly.

> Regarding image-mode, a simpler example of the bug is written as below.
> The hscroll does not change when the buffer is changed.
> Image display, window focus or message is not related.
>
> (let ((buf (generate-new-buffer "tmp")))
>   (switch-to-buffer buf)
>   (setq truncate-lines t)
>   (dotimes (i 200)
>     (insert (format ":%03d" i))
>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
>   (forward-char -1)
>   (sit-for 1)
>   (set-window-hscroll nil (window-hscroll))
>   (save-excursion
>     (forward-char -100)
>     (insert-char ?\n 10)
>     ))

Sorry, I don't think I follow: what exactly is the bug here?  What did
you expect to happen ,and what did actually happen?



Reply | Threaded
Open this post in threaded view
|

bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

ynyaaa
Eli Zaretskii <[hidden email]> writes:

>> Regarding image-mode, a simpler example of the bug is written as below.
>> The hscroll does not change when the buffer is changed.
>> Image display, window focus or message is not related.
>>
>> (let ((buf (generate-new-buffer "tmp")))
>>   (switch-to-buffer buf)
>>   (setq truncate-lines t)
>>   (dotimes (i 200)
>>     (insert (format ":%03d" i))
>>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
>>   (forward-char -1)
>>   (sit-for 1)
>>   (set-window-hscroll nil (window-hscroll))
>>   (save-excursion
>>     (forward-char -100)
>>     (insert-char ?\n 10)
>>     ))
>
> Sorry, I don't think I follow: what exactly is the bug here?  What did
> you expect to happen ,and what did actually happen?

The expression '(set-window-hscroll nil (window-hscroll))' should not
have any effect, but if it is deleted from the form, auto-hscroll-mode
works correctly.

Not only point motion but also buffer modification should be checked for
auto-hscroll-mode.



Reply | Threaded
Open this post in threaded view
|

bug#46316: 27.1; wrong horizontal scroll with truncate-lines value t

Eli Zaretskii
> From: [hidden email]
> Cc: [hidden email]
> Date: Mon, 15 Feb 2021 00:43:32 +0900
>
> >> (let ((buf (generate-new-buffer "tmp")))
> >>   (switch-to-buffer buf)
> >>   (setq truncate-lines t)
> >>   (dotimes (i 200)
> >>     (insert (format ":%03d" i))
> >>     (when (= 0 (% (1+ i) 100)) (insert ?\n)))
> >>   (forward-char -1)
> >>   (sit-for 1)
> >>   (set-window-hscroll nil (window-hscroll))
> >>   (save-excursion
> >>     (forward-char -100)
> >>     (insert-char ?\n 10)
> >>     ))
> >
> > Sorry, I don't think I follow: what exactly is the bug here?  What did
> > you expect to happen ,and what did actually happen?
>
> The expression '(set-window-hscroll nil (window-hscroll))' should not
> have any effect

That's not true: calling set-window-hscroll inhibits automatic
hscrolling, until point moves for some reason.

> but if it is deleted from the form, auto-hscroll-mode works
> correctly.

I think this is expected: the text your recipe adds is not around
point, so we don't re-enable auto-hscroll.

> Not only point motion but also buffer modification should be checked for
> auto-hscroll-mode.

If you want this to happen, don't call set-window-hscroll.