bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

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

Start "emacs -Q", and then evaluate (with M-:)

  (setq max-redisplay-ticks 3)

after the window containing *scratch* no longer redisplays, evalute

  (setq max-redisplay-ticks 3000000000000000)

and type M-x redraw-display RET.  The entire frame will become blank and
refuse to redisplay until a new frame is created.

In GNU Emacs 29.0.50 (build 192, x86_64-pc-linux-gnu, Motif Version 2.3.4)
 of 2022-06-24 built on trinity
Repository revision: 9f3ce27e56f5fa1053f2abcbcbd375cc0a75f283
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --with-dumping=unexec --with-x-toolkit=motif --without-cairo
 --cache-file=/tmp/ccache'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS UNEXEC WEBP X11 XDBE XFT
XIM XINPUT2 XPM MOTIF ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=none
  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 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
warnings iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-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 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 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 lcms2 dynamic-setting system-font-setting font-render-setting
motif x-toolkit xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 109667 8005)
 (symbols 48 21294 0)
 (strings 32 33643 1728)
 (string-bytes 1 917822)
 (vectors 16 17302)
 (vector-slots 8 565822 10894)
 (floats 8 63 64)
 (intervals 56 290 4)
 (buffers 992 12))

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

[Eli Zaretskii]

> Date: Fri, 24 Jun 2022 18:30:23 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> Start "emacs -Q", and then evaluate (with M-:)
> 
>   (setq max-redisplay-ticks 3)
> 
> after the window containing *scratch* no longer redisplays, evalute
> 
>   (setq max-redisplay-ticks 3000000000000000)
> 
> and type M-x redraw-display RET.  The entire frame will become blank and
> refuse to redisplay until a new frame is created.

Please try again.  (Your build seems to be without --enable-checking,
because with that I get assertion violation.)

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

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

Eli Zaretskii <eliz@gnu.org> writes:

> Please try again.  (Your build seems to be without --enable-checking,
> because with that I get assertion violation.)

Unfortunately, redraw-display still does nothing.

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 56184@debbugs.gnu.org
> Date: Fri, 24 Jun 2022 20:01:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please try again.  (Your build seems to be without --enable-checking,
> > because with that I get assertion violation.)
> 
> Unfortunately, redraw-display still does nothing.

What do you expect it to do?

If you type "C-x" and wait, does the "C-x" echo appear in the
minibuffer?  Is Emacs responsive in general, i.e. can you issue
commands, and do those commands produce the expected results?

IOW, "does nothing" tells me nothing, and I don't really understand
what is the problem you are describing, let alone why you think it's a
problem.

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

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

Eli Zaretskii <eliz@gnu.org> writes:

> What do you expect it to do?

To redraw the entire frame, since max-redisplay-ticks is now
sufficiently large.

> If you type "C-x" and wait, does the "C-x" echo appear in the
> minibuffer?  Is Emacs responsive in general, i.e. can you issue
> commands, and do those commands produce the expected results?

Yes, aside from redisplay not doing anything, causing redraw-display to
leave behind a completely blank frame.

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 56184@debbugs.gnu.org
> Date: Fri, 24 Jun 2022 21:08:15 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What do you expect it to do?
> 
> To redraw the entire frame, since max-redisplay-ticks is now
> sufficiently large.

That won't happen, unless you type C-l or make some change (e.g., type
a character) into *scratch*, because the buffer *scratch* is marked
"not to be redisplayed", and the only window on the frame is the
window showing *scratch*.  So this is the expected and documented
behavior.

> > If you type "C-x" and wait, does the "C-x" echo appear in the
> > minibuffer?  Is Emacs responsive in general, i.e. can you issue
> > commands, and do those commands produce the expected results?
> 
> Yes, aside from redisplay not doing anything

That's not really true, because the echo which appears in the echo
area and display of the characters you type in the minibuffer are
produced by redisplay.  So "not doing anything" is at least
inaccurate.  It just doesn't re4display the window which caused
problems, that's all.  As expected.

> causing redraw-display to leave behind a completely blank frame.

The frame has just one window, which is marked not to be displayed.
Try "C-x 4 b RET".

Bottom line: I don't see any bug here.  Aborting redisplay of a window
has got to produce some weird effects, like outdated display on the
glass, semi-empty or empty windows, etc.  What else should we expect
when we abandon redisplay of a window at some arbitrary point?

bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 56184@debbugs.gnu.org
>> Date: Fri, 24 Jun 2022 21:08:15 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > What do you expect it to do?
>> 
>> To redraw the entire frame, since max-redisplay-ticks is now
>> sufficiently large.
>
> That won't happen, unless you type C-l or make some change (e.g., type
> a character) into *scratch*, because the buffer *scratch* is marked
> "not to be redisplayed", and the only window on the frame is the
> window showing *scratch*.  So this is the expected and documented
> behavior.

Okay then, so I'm closing this bug.

Thanks.