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

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

[Eli Zaretskii]

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))

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> 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.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55193@debbugs.gnu.org
> Date: Sat, 30 Apr 2022 18:55:24 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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.