Therefore, sending it again to all On Sat, 4 Nov 2023 at 00:23, dalanicolai 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 wrote: > >> > From: dalanicolai >> > 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". >> >