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

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

[dalanicolai]

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

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:

```
(defun example ()
(interactive)

;; we make sure the warning buffer is already displayed, so that no
;; redisplay should occur on subsequent `lwarn' calls
(lwarn 'test :error "Here we only display the error buffer")

;; now we pop to an `example' buffer in a new window and create a
;; bunch of `page placeholders' (starting with a 'red' placeholder)
(pop-to-buffer "example")
(dotimes (i 20)
(let ((o (make-overlay
(point)
(progn (insert " ")
(point)))))
(insert "\n")
(overlay-put o 'face (list :background (if (= (% i 2) 0)
"red"
"blue")))
(overlay-put o 'display `(space . (:width (600) :height (800))))))

;; now we jump to some 'blue' placeholder (at buffer position 11),
;; currently offscreen, after which we try to update the
;; window-start position by redisplaying the buffer. To make sure
;; that the buffer will get 'redisplayed, we force it by calling the
;; `force-window-update' passing the `current buffer' as its
;; argument. Subsequently, we force trigger the `redisplay' by
;; calling `redisplay' while passing a non-nil `force' argument
;; Finally, we print the location of point and the location of
;; `window-start' to the terminal. Even though the `window-start'
;; position should have been updated by redisplaying the buffer
;; after calling `goto-char', it has not; it is still at 1 instead
;; of 11
(goto-char 11)

(print (format "Start: %s" (current-buffer)) #'external-debugging-output)

(force-window-update (current-buffer))
  (print (redisplay t) #'external-debugging-output)

(print (format "Point is %d" (point)) #'external-debugging-output)

  (lwarn 'test :error "This warning messes up the redisplay")
  (print (redisplay t) #'external-debugging-output)
(print (format "Buffer is: %s, window start is: %d:" (buffer-name)
(window-start))
      #'external-debugging-output))

(global-set-key (kbd "C-c e") 'example)
```

The explanation and instructions are in the comments within the
function. Additionally, I would like to mention that the 'bug' is due to
the (second) call to `lwarn'. Without the call to `lwarn' a simple 'unforced
redisplay' would have been enough to update the window-start.

We could also comment out the first `lwarn', in that case the second
`lwarn' triggers a redisplay, and the window-start gets
updated. However, I would expect window-start to get updated by the
`force-window-restart' and subsequently (force) triggering the
redisplay.



In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.17.8) of 2023-08-09 built on
 2a02-a45d-af56-1-666c-72af-583a-b92d.fixed6.kpn.net
Repository revision: 31cef9a4eac01fff5ff4fcb89d7e2b7815e93bad
Repository branch: HEAD
System Description: Fedora Linux 38 (Workstation Edition)

Configured using:
 'configure --with-tree-sitter --with-modules --with-cairo
 --with-native-compilation --with-json --with-pgtk'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER
XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 78059 6306)
 (symbols 48 7107 0)
 (strings 32 19405 1985)
 (string-bytes 1 600357)
 (vectors 16 16172)
 (vector-slots 8 329170 15654)
 (floats 8 28 46)
 (intervals 56 344 0)
 (buffers 984 12))

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

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

[Eli Zaretskii]

> 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".

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

[dalanicolai]

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

(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: 2493 bytes --]

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

[dalanicolai]

[-- 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 --]

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

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sat, 4 Nov 2023 00:23:30 +0100
> Cc: 66922@debbugs.gnu.org
> 
> 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).

Sorry, I didn't understand what you considered a "bug", because your
original description has all but drowned that in the long description
of what the code does.  So I thought that "messes redisplay" is the
problem, and that it alludes to the text from
external-debugging-output that appears inside the window of the TTY
frame.

If your problem is with window-start, then the reason for that is
simple: lwarn pops up the *Warnings* buffer, so the call to
window-start returns the value for that buffer, not for the "example"
buffer.  If, after running the recipe, you do

  C-x b RET
  M-: (window-start) RET

you will see that window-start in "example" is 11, as you expect.

So I see no bug here.

> (Also obviously, I can not use a normal print/message, when
> 'investigating' redisplay issues)

Of course, you can: use 'message', and then look in the *Messages*
buffer.

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

[dalanicolai]

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

Thank you for looking again at it Eli,

in the recipe, I am printing the buffer-name and the window-start
together (where the buffer-name gets evaluated before window-start),
and it says that the buffer-name is 'example'. So I expected
(window-start) to return the window-start from the window displaying
the example buffer.

I already wanted to write you that this must be the case, but I
thought let me first try to print the buffer of the selected-window.
In that case, indeed, it shows that the selected-window is that of the
warning buffer.

Finally, I understand now that the current-buffer is not per se the same
as the buffer displayed in the selected window. I understand it now, but
until now that was not obvious to me.

Thanks again Eli, for clearing things up!

On Sat, 4 Nov 2023 at 08:13, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Sat, 4 Nov 2023 00:23:30 +0100
> > Cc: 66922@debbugs.gnu.org
> >
> > 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).
>
> Sorry, I didn't understand what you considered a "bug", because your
> original description has all but drowned that in the long description
> of what the code does.  So I thought that "messes redisplay" is the
> problem, and that it alludes to the text from
> external-debugging-output that appears inside the window of the TTY
> frame.
>
> If your problem is with window-start, then the reason for that is
> simple: lwarn pops up the *Warnings* buffer, so the call to
> window-start returns the value for that buffer, not for the "example"
> buffer.  If, after running the recipe, you do
>
>   C-x b RET
>   M-: (window-start) RET
>
> you will see that window-start in "example" is 11, as you expect.
>
> So I see no bug here.
>
> > (Also obviously, I can not use a normal print/message, when
> > 'investigating' redisplay issues)
>
> Of course, you can: use 'message', and then look in the *Messages*
> buffer.
>

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

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

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sat, 4 Nov 2023 12:07:49 +0100
> Cc: 66922@debbugs.gnu.org
> 
> Thank you for looking again at it Eli,
> 
> in the recipe, I am printing the buffer-name and the window-start
> together (where the buffer-name gets evaluated before window-start),
> and it says that the buffer-name is 'example'. So I expected
> (window-start) to return the window-start from the window displaying
> the example buffer.
> 
> I already wanted to write you that this must be the case, but I
> thought let me first try to print the buffer of the selected-window.
> In that case, indeed, it shows that the selected-window is that of the
> warning buffer. 
> 
> Finally, I understand now that the current-buffer is not per se the same
> as the buffer displayed in the selected window. I understand it now, but
> until now that was not obvious to me.
> 
> Thanks again Eli, for clearing things up!

I'm glad I could be of help.

I'm therefore closing this bug.