bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#56184: 29.0.50; Increasing max-redisplay-ticks after it is set very low does nothing
Date: Fri, 24 Jun 2022 16:29:57 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]