From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 03 14:08:51 2023 Received: (at submit) by debbugs.gnu.org; 3 Nov 2023 18:08:51 +0000 Received: from localhost ([127.0.0.1]:59722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyybC-0004Yl-9h for submit@debbugs.gnu.org; Fri, 03 Nov 2023 14:08:51 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyybA-0004YV-ER for submit@debbugs.gnu.org; Fri, 03 Nov 2023 14:08:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyyaT-000710-3Y for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 14:08:05 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyyaQ-0002Pv-96 for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 14:08:04 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-40806e4106dso14883855e9.1 for ; Fri, 03 Nov 2023 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699034878; x=1699639678; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=KgO3Mvpj0KRSGZXQAUx+RN81LhpuqTHw5Ixl+M7Blxc=; b=V8L1qVOx9qwJXykqnfGPdKvj+5Ijb8zQogf/T0a4zNuz8CYbTYSNvl2iVB6NdjIigm HeyXskD4YVe7KTJvMUAMZpa4Tm1ptHaDt+//VS4oz+eDuTOQlI5u1JYy+40ETZmUj19f wAn3BjJwoNuCZ/2IuMRsVjisiT3WLCGPBRjcE3NazJZZ8o41udqRK5ztxphsy5mBHrGV C5Jj5BB8ur2zBMNQy4fQ0MkTQn3UWp0KlFxsVYRKdsWZsRZY+iHxyXoQDuAs/zQQKDC+ TlCNUm63KqUl3Hi//lUFMzOQ7NwIjdi7nj4A2N/GhcV4Y6c93j0rtS8H839dLyPGhtbj znjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699034878; x=1699639678; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KgO3Mvpj0KRSGZXQAUx+RN81LhpuqTHw5Ixl+M7Blxc=; b=K9EDNpFtPr/vqMhSp9KqUe4Bznc5GgTxSOKEVfUHqZno9W3ToXnmZ+G1bd974F58CB E7zEuQU+vONIonrfvP3PyBiCQanj1h5rS892kXRjExpX+ILQkfwqVdKUxjPJplX9oQLA rSrBjLPXqzV6m0P4vvfna+ayCKiv/N/AnrgTtaG9JfyLcijaXaHXFekVlEVK1wpHfGgt KM45n9zS2PT/XTxs6nT3qRz7u8JTiTsrKn1Or230ZdfES18G183+VunxQsZj+++cMVY7 RCAfgr0lrRHC9+q1PIE6SNuo/hAymhuOBWv/hvMJAe4Zq8MAFEXPGKKRK8arp6b9sOAP uMJA== X-Gm-Message-State: AOJu0Yx0NyPUDJslmKlPx0QmtNZe/ZFMFNjSpctuR3H/56w43+gZ+2K6 0YTB2fUYxOUxO5pTseyWL3BlzbeejwmBBEYLmONZb33ZWhk= X-Google-Smtp-Source: AGHT+IHZ0oPXsqStY17vYSTcA2dNS54ya4wtoKhl8oDeYNOjF7Kn0PLd/N2VSLLrJtBtc2Pj/J6EbQFTjKpuCKs8IPQ= X-Received: by 2002:a05:600c:458f:b0:401:c8b9:4b86 with SMTP id r15-20020a05600c458f00b00401c8b94b86mr4139133wmo.9.1699034878260; Fri, 03 Nov 2023 11:07:58 -0700 (PDT) MIME-Version: 1.0 From: dalanicolai Date: Fri, 3 Nov 2023 19:07:47 +0100 Message-ID: Subject: 29.1; No redisplay of buffer, even after using `force-window-update' To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000613a940609436208" Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=dalanicolai@gmail.com; helo=mail-wm1-x331.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000613a940609436208 Content-Type: text/plain; charset="UTF-8" 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)) --000000000000613a940609436208 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was trying to debug my 'image roll' package, tha= t provides a 'virtual
scroll' for displaying documents (i.e. boo= ks), when I encountered the
following 'bug'. To reproduce it fro= m emacs -Q, just evaluate the
following code and press `C-c e`; note tha= t relevant debugging output
will be printed to the terminal:

```<= br>(defun example ()
(interactive)

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

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

;; now we jump to some 'blue&#= 39; 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 `curre= nt buffer' as its
;; argument. Subsequently, we force trigger the `= redisplay' by
;; calling `redisplay' while passing a non-nil `f= orce' argument
;; Finally, we print the location of point and the l= ocation of
;; `window-start' to the terminal. Even though the `wind= ow-start'
;; position should have been updated by redisplaying the = buffer
;; after calling `goto-char', it has not; it is still at 1 i= nstead
;; of 11
(goto-char 11)

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

(force-= window-update (current-buffer))
=C2=A0 (print (redisplay t) #'extern= al-debugging-output)

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

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

(global-set-key (kbd &q= uot;C-c e") 'example)
```

The explanation and instructio= ns are in the comments within the
function. Additionally, I would like t= o mention that the 'bug' is due to
the (second) call to `lwarn&#= 39;. Without the call to `lwarn' a simple 'unforced
redisplay= 9; would have been enough to update the window-start.

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



In GNU E= macs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
=C2=A0cai= ro version 1.17.8) of 2023-08-09 built on
=C2=A02a02-a45d-af56-1-666c-72af-5= 83a-b92d.fixed6.kpn.net
Repository revision: 31cef9a4eac01fff5ff4fcb= 89d7e2b7815e93bad
Repository branch: HEAD
System Description: Fedora = Linux 38 (Workstation Edition)

Configured using:
=C2=A0'confi= gure --with-tree-sitter --with-modules --with-cairo
=C2=A0--with-native-= compilation --with-json --with-pgtk'

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

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

Major mode: Lisp Interaction

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

Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-medi= a puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derive= d epg rfc6068
epg-config gnus-util text-property-search time-date mm-dec= ode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailhead= er 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 rfc204= 5
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv<= br>eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
eli= sp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar = dnd fontset image regexp-opt fringe tabulated-list replace
newcomment te= xt-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow i= search 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 tib= etan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek rom= anian slovak czech european ethiopic indian
cyrillic chinese composite e= moji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbr= ev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cu= s-face macroexp files window
text-properties overlay sha1 md5 base64 for= mat env code-pages mule
custom widget keymap hashtable-print-readable ba= ckquote threads dbusbind
inotify dynamic-setting system-font-setting fon= t-render-setting cairo
gtk pgtk multi-tty make-network-process native-co= mpile emacs)

Memory information:
((conses 16 78059 6306)
=C2= =A0(symbols 48 7107 0)
=C2=A0(strings 32 19405 1985)
=C2=A0(string-by= tes 1 600357)
=C2=A0(vectors 16 16172)
=C2=A0(vector-slots 8 329170 1= 5654)
=C2=A0(floats 8 28 46)
=C2=A0(intervals 56 344 0)
=C2=A0(buf= fers 984 12))
--000000000000613a940609436208-- From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 03 14:51:39 2023 Received: (at 66922) by debbugs.gnu.org; 3 Nov 2023 18:51:39 +0000 Received: from localhost ([127.0.0.1]:59750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyzGd-0005kZ-3G for submit@debbugs.gnu.org; Fri, 03 Nov 2023 14:51:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyzGa-0005kH-Js for 66922@debbugs.gnu.org; Fri, 03 Nov 2023 14:51:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyzFu-0003ut-GT; Fri, 03 Nov 2023 14:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4M279Ji+VP2pCogyF775wzPdd7oItc/SzfbPygx9WWQ=; b=MJa5KIGVQBW1 pbjqPB4INPxCXSpQGiHrZ+mrXH3zHttk0i2oL2DWt/xHCg2FvFWHbhDD8tByf+RY5/PB0j9wNTEGH x1tLA35/9RFOlsu5l0vLdZv0PBWkO6UJRSEt/M9GQemk44HFeRGTTe97hDp2zqyjyoKog7lV0qoAT nH3pOblEFuszw6H3nq60BJXaDrZHbg6PV5tpFVavSNQPDxO/tyg/aqIFANdLgEnRPtNoS/BUScWgM JeB3rGdta5el4nJiofkEzNfRj8XnQFkv8HR97MhUQPc7OiOwJQzQlKVAWjnGz/2klohRXSpSLQZ8v bBIGjVWozJwaqzppynXoPA==; Date: Fri, 03 Nov 2023 20:50:49 +0200 Message-Id: <8334xm7jsm.fsf@gnu.org> From: Eli Zaretskii To: dalanicolai In-Reply-To: (message from dalanicolai on Fri, 3 Nov 2023 19:07:47 +0100) Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66922 Cc: 66922@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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". From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 03 19:24:26 2023 Received: (at 66922) by debbugs.gnu.org; 3 Nov 2023 23:24:27 +0000 Received: from localhost ([127.0.0.1]:60034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Wc-0004iH-DV for submit@debbugs.gnu.org; Fri, 03 Nov 2023 19:24:26 -0400 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:52726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Wa-0004hz-2v for 66922@debbugs.gnu.org; Fri, 03 Nov 2023 19:24:24 -0400 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2c503da4fd6so34966771fa.1 for <66922@debbugs.gnu.org>; Fri, 03 Nov 2023 16:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699053822; x=1699658622; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JS1mVLgL+BVYDKcHqKZ5gjeVKLWBm2B0H451IryH3qI=; b=Rusu3de5xDErYr26AHl2xMmjwLxdCBTqeEso/dHTkI1oTsY7lG776LLC629UKuRB+N MwrlKDkmkXvGdS1ifS/wQQ+o48+RRb6BuwKmYki29I4hnazIaKBMXuLxsD3O+8uOt/hw +4LeOftmxikCuvju2fc/BThRZjwPCgAiDE2ZaqHKiCr6oq7v4DM/G3lBITwhMu5sRNX5 Ron5JXK9X8KAborza8agSvWT7jO2Y7TvygugjLAHHAH5P1J7AgTk/LksWZd2TC9bYIqm NJQi94gPfRb+sghQ3Pai+ZDj9pqI7fr+iNNud73w4iuVz3FV5N1sr3wzdTGaiuG31V82 kKTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699053822; x=1699658622; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JS1mVLgL+BVYDKcHqKZ5gjeVKLWBm2B0H451IryH3qI=; b=XgGtqYRjxt+GF+I45fdHwwj6hURc0DNdf6RC3tDTDFKQCZt0ojckpM8piDUIt/vmS7 N9oZLVqo0cl0ZNjicCOX44hYGDQOYwckJ9klWaHl7M+uFq08wr7yxRAtoY4udpmrpXOM XMlmlYi2BLU9JNOSvLYgv/UR2hSHQDz5r+GxFXydhMDN2vxSI9hIQ+7kJd4Sm06knRpz pfYd+DfiH0VHsb+D6RvM1wugEAvbTnKK4/gUKCSnw1ZLHagUWSi0HwfP+TFR8gG9b1mV D2ZE0ASBbCiSYbknE1QaHxrZZU4J+sHH7YvWi556MOCE1yt78D/uZp743zaJTMWNwL2W CMYQ== X-Gm-Message-State: AOJu0YwXG1VyS1eOmCDPJ0sTsjQd4YJ3k15FxhBkqJQFlU6swHQQdk39 YYamKmoueowJInQNdvShmoOXTXGNznqClJUZ8fE= X-Google-Smtp-Source: AGHT+IHbu1GgZ5GAaioG6y5mg515lXhM7X4ZWlVwdvwxsCS4QWoZmOhlmyFvb8vSDmMqbptptKhqT+H2WXha6kqfjcI= X-Received: by 2002:a05:651c:39a:b0:2c5:ee7:b322 with SMTP id e26-20020a05651c039a00b002c50ee7b322mr17691293ljp.18.1699053821787; Fri, 03 Nov 2023 16:23:41 -0700 (PDT) MIME-Version: 1.0 References: <8334xm7jsm.fsf@gnu.org> In-Reply-To: <8334xm7jsm.fsf@gnu.org> From: dalanicolai Date: Sat, 4 Nov 2023 00:23:30 +0100 Message-ID: Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000008083c6060947cbdc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66922 Cc: 66922@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008083c6060947cbdc Content-Type: text/plain; charset="UTF-8" (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". > --0000000000008083c6060947cbdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Sorry, I used the wrong reply button)

=
Sorry Eli, I don't know what you mean here. Over here the pr= oblem does
occur also in the GUI, and I am using the print to
'ex= ternal-debugging-output' because the lwarn is what causes the
proble= m. I explained in the bug report that the window-start does not
get upda= ted 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)<= br>
The documentation says that redisplay should recalculate the
wind= ow-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 la= st output printed to the terminal, it shows that the
window-start is sti= ll at 1, while it should be at 11, because I
applied the 'force-wind= ow-update' incl. the redisplay after the
(goto-char 11).

Is t= here something I am not understanding correctly? Or could I
consider it = a bug in the documentation? As far as I know, I checked
the documentatio= n and the behavior quite rigidly.

On Fri, 3 Nov 2023 at 19:50, Eli Zar= etskii <eliz@gnu.org> wrote:
<= /div>
> From: dalanicol= ai <dalanicol= ai@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<= br> > will be printed to the terminal:

The problem only happens in "emacs -nw", not on a GUI frame.=C2= =A0 And I
wonder why you consider this a bug.=C2=A0 I think external-debugging-output=
is documented to print to stderr, so the "mess-up" is expected.= =C2=A0 I'd
say "don't do that".
--0000000000008083c6060947cbdc-- From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 03 19:25:48 2023 Received: (at 66922) by debbugs.gnu.org; 3 Nov 2023 23:25:48 +0000 Received: from localhost ([127.0.0.1]:60038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Xw-0004kg-1R for submit@debbugs.gnu.org; Fri, 03 Nov 2023 19:25:48 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:47420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qz3Xt-0004kP-Hk for 66922@debbugs.gnu.org; Fri, 03 Nov 2023 19:25:46 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4084e49a5e5so22140275e9.3 for <66922@debbugs.gnu.org>; Fri, 03 Nov 2023 16:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699053904; x=1699658704; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KdD1ReLsXXtoWxfGV4E2G/O/tmqog4hjzCZXkrN+YMM=; b=MPaI+kG5Zo4ncccG/2mlmhRh+oNtdg48jYNaOGzSw3PqOV2LDY/EvV4a3TxHJIV+nH v4WFtTbUXlGDnMmIORIrl5DQPKHF1IrvrgIFLGF537hiR8nNLAWKzR0imy0pvnL4ObnE KwxsNNGoVw5eTulYZI9afGMC1kzoBLnvXwOncyeJQyMZ84wfPkdGWXpLlKfMMIzsFizw Rewcmg2mtpHziYJ6MoExNyM2BMiSIIdtgLAb5OMOCY2X9bcHebpCxyD2zhDSInH6HzSy DyUQQK03a7Il3QZ7266Xzg24P79Tjf0Vn/QzMomts5haHgorVgLqQGjuIIqyuIAdOPoI +Z3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699053904; x=1699658704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KdD1ReLsXXtoWxfGV4E2G/O/tmqog4hjzCZXkrN+YMM=; b=H2omDnbHqFl1/EPsqYFrGLiLFW7DyOujjE67ECt8lKqacnYK1QwPZh5fSCo7g6bHMn cpQJ7m1HpN++oR/45Pdrbtd70jyT5ZpqRUtbFMOatmUlMc0XorLq/kPTHCWfUR+IV31E DiNB9nYa8LDnmDyf83t5dmlS+fx0v9CQqjOoT4C4rsoBWIY8Zsd0HwiYAJiUQmD32nlS ppTU96jZd9BeWl69ih6qgRlzkIZsZzWltoQx0lrUYvhw1DoETEpX0DzV4k1+avuEPJ6P w0u0uTeRrbwH5DYkxBv+QDnRQfX63O5oQ30uQypX3oyijfPHhktds1aegGCnA2mHwg1l MRiw== X-Gm-Message-State: AOJu0YxfnD0dmhmGkk+9gG5pp5TXoMNkO6uS5j7+mUhqc3itxeZR4W+Z 7lCDp1EJdP+jml6tknJuSrNy8B78T0FwU0KmsZFZUQyP X-Google-Smtp-Source: AGHT+IGNmDthfEQ64qTPahw6L+i2eGzjb1COmFX1k7X/YRh+h2m2tX5wNADgXl4H9YNEtAEk0HYirjo5AEHTulEVHhY= X-Received: by 2002:a05:600c:1caa:b0:405:1bbd:aa9c with SMTP id k42-20020a05600c1caa00b004051bbdaa9cmr18761433wms.34.1699053903576; Fri, 03 Nov 2023 16:25:03 -0700 (PDT) MIME-Version: 1.0 References: <8334xm7jsm.fsf@gnu.org> In-Reply-To: From: dalanicolai Date: Sat, 4 Nov 2023 00:24:52 +0100 Message-ID: Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000060826e060947d003" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66922 Cc: 66922@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000060826e060947d003 Content-Type: text/plain; charset="UTF-8" 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". >> > --00000000000060826e060947d003 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Therefore, sending it again to all

On Sat, 4 Nov 2023 a= t 00:23, dalanicolai <dalanicol= ai@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 t= o
'external-debugging-output' because the lwarn is what causes t= he
problem. I explained in the bug report that the window-start does not=
get updated when including the lwarn after the forced redisplay (thepoint is at 11, but window-start is still at 1).

(Also obviously, I= can not use a normal print/message, when
'investigating' redisp= lay issues)

The documentation says that redisplay should recalculate= the
window-start, and that by using force-window-update, we can ensure<= br>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
lo= ok 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 = 9;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 <el= iz@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<= br> > will be printed to the terminal:

The problem only happens in "emacs -nw", not on a GUI frame.=C2= =A0 And I
wonder why you consider this a bug.=C2=A0 I think external-debugging-output=
is documented to print to stderr, so the "mess-up" is expected.= =C2=A0 I'd
say "don't do that".
--00000000000060826e060947d003-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 04 03:14:15 2023 Received: (at 66922) by debbugs.gnu.org; 4 Nov 2023 07:14:15 +0000 Received: from localhost ([127.0.0.1]:60329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzArH-0005Y6-0f for submit@debbugs.gnu.org; Sat, 04 Nov 2023 03:14:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzArE-0005Xq-2M for 66922@debbugs.gnu.org; Sat, 04 Nov 2023 03:14:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzAqY-0007zv-Hy; Sat, 04 Nov 2023 03:13:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4T6mr8m2mSWYdtuOCD8il2zrCL85/A5xTRPnUHnEwbc=; b=EuCHbg9Wtnbv FGY25DIcMjQJf39RaJk22kqBZpNZLeCiP8PCARm6Z3GAN+Tgj4loMzpRx8Kxa+16zT4gNrOaRG/3U QgSNh/nldW2hAZjBJWUkYZQrwG8xsj/iEEW1tMOoE9xVXNmjw5PXm5ATx6zTTrav6jwKwriX2qNbG 7IQvvQmqDX8YXwQMstifc1sN9Vk/TrGHmSjdoMfPAHSDS6JY4m+Mck1gwgIAaTnB+vmxlPsGhCO4q WCgiojnknfs76y0X1wPf0lxZoL7vTWRHgYRctm3zW10tcKFedpPRW2YBBtxbg8QEvWfFZ9ClDldC7 NWFQP/4nPFW2P2Tjh8Hjpg==; Date: Sat, 04 Nov 2023 09:13:25 +0200 Message-Id: <83r0l656ui.fsf@gnu.org> From: Eli Zaretskii To: dalanicolai In-Reply-To: (message from dalanicolai on Sat, 4 Nov 2023 00:23:30 +0100) Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' References: <8334xm7jsm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66922 Cc: 66922@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: dalanicolai > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 04 07:08:47 2023 Received: (at 66922) by debbugs.gnu.org; 4 Nov 2023 11:08:47 +0000 Received: from localhost ([127.0.0.1]:32991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzEWE-0003ra-PE for submit@debbugs.gnu.org; Sat, 04 Nov 2023 07:08:47 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:43336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzEWC-0003rJ-3L for 66922@debbugs.gnu.org; Sat, 04 Nov 2023 07:08:45 -0400 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40907b82ab9so23141005e9.1 for <66922@debbugs.gnu.org>; Sat, 04 Nov 2023 04:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699096082; x=1699700882; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QKow8QoHeu79jI/Wh85de9HXgFTw3dE+iAlO/UsDVu8=; b=jHLWc/fog8IcuKG5Nujpcws7RX5N/QZvEbid/rLd4iNd/GIve1a0PFLa+WOVk6kW7B GaYx+cDqLwTnzU8XNmmXItnndwRJ6QP6y5dfFboTFJwZ/cX50pHkja/kNdXs67TtxYVj GBtzMiGta5Whb17qQzwSzQkHOnb+A+FqfWPd3WZEBSGDaX+JG8+Fj2LneyVKn/nWQOWk xMizZGN3WZCbYZ7wWJv1L9N/Tw9XC4gfRTil5AGl8gOjwW0vUMULDGFiFgakln/U5p6e Fz1AISZJKGSO8OQ7MyAAOV9wHtRgZ07dAuIM/kUfBNW/4iwmbj0xa1o9ebkwu7UVzLMf 8m9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699096082; x=1699700882; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QKow8QoHeu79jI/Wh85de9HXgFTw3dE+iAlO/UsDVu8=; b=luaUtrGe0l/PRo1SUHCEZhr/NNamRv+X7Mg7vj6hY/7K3bSzoESV9/0CrDn3drL600 65rvDMYcCp9qCXr6gnPOwcLswr0Dd2SAJ/Kj29JqcW2ONNAnscNX/KhJpZ2JEJSlbq5Q QKO4FZ765Y+db5l2uZQXj2C/QYoRGWhS2NzyWgGn/ty82JtjnhfVyAiwNTNlZQJg5cZn V9ZzsfksL4UlFQ268XBu7LuN/P3z/iMwSkm2Wg7+eiv8aKLokfPS6H+nPBJxCiwoQuVZ E9FDyDyCgvIRtdjR6j/dtSgv+ksN5RXX/SOHwNdzoDvQ/EIC6ECVABEBrSrxV9Cor4cP W8hA== X-Gm-Message-State: AOJu0YxG65/Nh/7LerTvnxby6SftRRss+nnETeclCx8VToHTfjp2m5a3 mOeGFiuP4gTHn2QSPUcgticdlxZBLKbbDu1WAqsppwO8YK0= X-Google-Smtp-Source: AGHT+IF76484ZW05hyMvFhMKSvDIm+Fg4U1C3R3PZQ7W1jsnVXQrfW3L0jQQVm8zjohDuwHlXqMpQNofKb7ZBHKBBcY= X-Received: by 2002:a05:6000:1a85:b0:32d:dd68:e83 with SMTP id f5-20020a0560001a8500b0032ddd680e83mr5149123wry.21.1699096081685; Sat, 04 Nov 2023 04:08:01 -0700 (PDT) MIME-Version: 1.0 References: <8334xm7jsm.fsf@gnu.org> <83r0l656ui.fsf@gnu.org> In-Reply-To: <83r0l656ui.fsf@gnu.org> From: dalanicolai Date: Sat, 4 Nov 2023 12:07:49 +0100 Message-ID: Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000636111060951a24b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66922 Cc: 66922@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000636111060951a24b Content-Type: text/plain; charset="UTF-8" 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 wrote: > > From: dalanicolai > > 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. > --000000000000636111060951a24b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for looking again at it Eli,

in the recip= e, I am printing the buffer-name and the window-start
together (where th= e 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 cas= e, indeed, it shows that the selected-window is that of the
warning buff= er.

Finally, I understand now that the current-buff= er 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@d= ebbugs.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 t= he
> problem. I explained in the bug report that the window-start does not<= br> > 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", becau= se your
original description has all but drowned that in the long description
of what the code does.=C2=A0 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&q= uot;
buffer.=C2=A0 If, after running the recipe, you do

=C2=A0 C-x b RET
=C2=A0 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*<= br> buffer.
--000000000000636111060951a24b-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 04 07:18:35 2023 Received: (at 66922-done) by debbugs.gnu.org; 4 Nov 2023 11:18:35 +0000 Received: from localhost ([127.0.0.1]:33011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzEfj-00049j-2H for submit@debbugs.gnu.org; Sat, 04 Nov 2023 07:18:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzEfi-00049X-AY for 66922-done@debbugs.gnu.org; Sat, 04 Nov 2023 07:18:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzEf1-00034r-44; Sat, 04 Nov 2023 07:17:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PVUz8F8MAJ54kXPI8kVdzuBs4oX+rXgIL0Pc2WbhzTM=; b=CXCPtiGAXP6q X0o2NMn8vAN3IDllAYtyYKeF2RU+3zbZ3NTPAsPRF9f87NOwf1zXhXBM1NwxSrXoFZPWJVyb9jRId /8oQJwb50JK3iebMiZ9OpuLn1sXKaDxv8HOqgEXW7xDY+jMe2nQadKth7vl/CY2G8RILxk0/mwgsE YMVDPPkhHGqTvtXjV0xTvKskRSUAdJBFIeNymPSI+tfzxeG4Oi0oCoZft5dNlnFF7Lt8v5ZNLPzc7 WF1+B44I+zR2bNvSxqWZDABJVGINqvJaYOqIHqh0N07X+akSMxEwy+wecgTpDlgWk8TSstKE4f8fS LIDGG7HWlLBdV91xacQGUw==; Date: Sat, 04 Nov 2023 13:17:43 +0200 Message-Id: <83ttq14vjc.fsf@gnu.org> From: Eli Zaretskii To: dalanicolai In-Reply-To: (message from dalanicolai on Sat, 4 Nov 2023 12:07:49 +0100) Subject: Re: bug#66922: 29.1; No redisplay of buffer, even after using `force-window-update' References: <8334xm7jsm.fsf@gnu.org> <83r0l656ui.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66922-done Cc: 66922-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: dalanicolai > 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. From unknown Thu Aug 21 14:53:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 02 Dec 2023 12:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator