GNU bug report logs - #55193
29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sat, 30 Apr 2022 09:50:02 UTC

Severity: normal

Found in version 29.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55193 in the body.
You can then email your comments to 55193 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#55193; Package emacs. (Sat, 30 Apr 2022 09:50:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eli Zaretskii <eliz <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 30 Apr 2022 09:50:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Double-buffering on MS-Windows freezes cursor in minibuffer
Date: Sat, 30 Apr 2022 12:49:12 +0300
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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55193; Package emacs. (Sat, 30 Apr 2022 10:56:01 GMT) Full text and rfc822 format available.

Message #8 received at 55193 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55193 <at> debbugs.gnu.org
Subject: Re: bug#55193: 29.0.50; Double-buffering on MS-Windows freezes
 cursor in minibuffer
Date: Sat, 30 Apr 2022 18:55:24 +0800
Eli Zaretskii <eliz <at> 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.




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 30 Apr 2022 11:08:01 GMT) Full text and rfc822 format available.

Notification sent to Eli Zaretskii <eliz <at> gnu.org>:
bug acknowledged by developer. (Sat, 30 Apr 2022 11:08:01 GMT) Full text and rfc822 format available.

Message #13 received at 55193-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 55193-done <at> debbugs.gnu.org
Subject: Re: bug#55193: 29.0.50; Double-buffering on MS-Windows freezes
 cursor in minibuffer
Date: Sat, 30 Apr 2022 14:07:39 +0300
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 55193 <at> debbugs.gnu.org
> Date: Sat, 30 Apr 2022 18:55:24 +0800
> 
> Eli Zaretskii <eliz <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 28 May 2022 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 331 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.