bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update'

[dalanicolai <dalanicolai@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

Therefore, sending it again to all

On Sat, 4 Nov 2023 at 00:23, dalanicolai <dalanicolai@gmail.com> wrote:

> (Sorry, I used the wrong reply button)
>
> Sorry Eli, I don't know what you mean here. Over here the problem does
> occur also in the GUI, and I am using the print to
> 'external-debugging-output' because the lwarn is what causes the
> problem. I explained in the bug report that the window-start does not
> get updated when including the lwarn after the forced redisplay (the
> point is at 11, but window-start is still at 1).
>
> (Also obviously, I can not use a normal print/message, when
> 'investigating' redisplay issues)
>
> The documentation says that redisplay should recalculate the
> window-start, and that by using force-window-update, we can ensure
> that some buffer or window gets redisplayed on the next redisplay.
>
> Now if you evaluate the code, from the bug report in GUI emacs, and
> look at the last output printed to the terminal, it shows that the
> window-start is still at 1, while it should be at 11, because I
> applied the 'force-window-update' incl. the redisplay after the
> (goto-char 11).
>
> Is there something I am not understanding correctly? Or could I
> consider it a bug in the documentation? As far as I know, I checked
> the documentation and the behavior quite rigidly.
>
> On Fri, 3 Nov 2023 at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: dalanicolai <dalanicolai@gmail.com>
>> > Date: Fri, 3 Nov 2023 19:07:47 +0100
>> >
>> > I was trying to debug my 'image roll' package, that provides a 'virtual
>> > scroll' for displaying documents (i.e. books), when I encountered the
>> > following 'bug'. To reproduce it from emacs -Q, just evaluate the
>> > following code and press `C-c e`; note that relevant debugging output
>> > will be printed to the terminal:
>>
>> The problem only happens in "emacs -nw", not on a GUI frame.  And I
>> wonder why you consider this a bug.  I think external-debugging-output
>> is documented to print to stderr, so the "mess-up" is expected.  I'd
>> say "don't do that".
>>
>

[-- Attachment #2: Type: text/html, Size: 2903 bytes --]