Subject: bug#55193: closed (Re: bug#55193: 29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 30 Apr 2022 11:08:01 +0000

Your bug report

#55193: 29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
55193: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55193
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#55193: 29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer
From: Eli Zaretskii <[email-masked]>
To: Po Lu <[email-masked]>
Cc: [email-masked]
Date: Sat, 30 Apr 2022 14:07:39 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Po Lu <[email-masked]>
> Cc: [email-masked]
> Date: Sat, 30 Apr 2022 18:55:24 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > The new double-buffering feature on MS-Windows causes unpleasant side
> > effect when the user types something into the minibuffer, then presses
> > RET to submit and exit the minibuffer.  Without double-buffering, the
> > cursor moves to the beginning of the minibuffer, thus providing visual
> > feedback that whatever the user typed was submitted.  With
> > double-buffering turned on, the cursor "freezes" in its last position,
> > at the end of the minibuffer text, until the command finishes and
> > redisplay does its job.  Which could be a tangible amount of time,
> > during which Emacs looks "frozen".
> >
> > To reproduce:
> >
> >   emacs -Q
> >   M-x blink-cursor-mode RET
> >   C-x C-f src/xdisp.c RET
> >
> > Observe that the cursor is at the end of the file name until such time
> > as xdisp.c is displayed, which could be a second or two in a
> > non-optimized build of Emacs.
> >
> > Can this be avoided, please, i.e. can we update the display after the
> > cursor is moved?
> 
> Thanks, should be fixed now.

Indeed, thanks.

Subject: 29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer
From: Eli Zaretskii <[email-masked]>
To: [email-masked]
Date: Sat, 30 Apr 2022 12:49:12 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

The new double-buffering feature on MS-Windows causes unpleasant side
effect when the user types something into the minibuffer, then presses
RET to submit and exit the minibuffer.  Without double-buffering, the
cursor moves to the beginning of the minibuffer, thus providing visual
feedback that whatever the user typed was submitted.  With
double-buffering turned on, the cursor "freezes" in its last position,
at the end of the minibuffer text, until the command finishes and
redisplay does its job.  Which could be a tangible amount of time,
during which Emacs looks "frozen".

To reproduce:

  emacs -Q
  M-x blink-cursor-mode RET
  C-x C-f src/xdisp.c RET

Observe that the cursor is at the end of the file name until such time
as xdisp.c is displayed, which could be a second or two in a
non-optimized build of Emacs.

Can this be avoided, please, i.e. can we update the display after the
cursor is moved?

In GNU Emacs 29.0.50 (build 952, i686-pc-mingw32)
 of 2022-04-30 built on HOME-C4E4A596F7
Repository revision: 7b7a124afa0a71f4847ddc5a3934b02ab5d46d2c
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

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 rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win 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 simple cl-generic 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 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
w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 49118 7913)
 (symbols 48 6888 1)
 (strings 16 19126 2798)
 (string-bytes 1 536222)
 (vectors 16 11253)
 (vector-slots 8 161083 8684)
 (floats 8 22 53)
 (intervals 40 268 69)
 (buffers 888 10))