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

[ynyaaa]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 46316@debbugs.gnu.org
>> From: ynyaaa@gmail.com
>> Date: Mon, 08 Feb 2021 00:28:57 +0900
>> 
>> > I don't think this behavior is a bug.  We only change the hscroll of a
>> > window when point moves, and in these two scenarios it doesn't move.
>> > I see no reason to assume that the user will necessarily want to have
>> > the window scroll, instead of keeping it at its current horizontal
>> > scroll.
>> 
>> In the case of isearch, the hscroll is changed without point motion
>> when isearch fails.
>
> Yes, because the focus changes into the minibuffer, where we show the
> failure message.
>
>> In the case of image-toggle-display, the hscroll is changed without
>> point motion when typing 'C-c C-c' for the first time.
>
> Yes, and for a similar good reason.

When emacs misses the appropriate hscroll, typing 'M-: t RET' changes
the forcus into the minibuffer temporally, but does not change the
hscroll of the original buffer.

> I don't really understand the insistence: you can easily cause the
> window to auto-scroll if you move point by one character.  Emacs
> cannot possibly guess which part of the display is more important for
> the user in situations like this.

I only want auto-hscroll-mode to scroll buffer automatically.
Otherwise I will be very confused.
If a searched string is not displayed in the window, I might think the
searched string does not exist in the buffer.
If an image is hidden, I might think the image is a solid color same as
the emacs background color.