bug#18722: Correction

[Eli Zaretskii]

> From: Titus von der Malsburg <malsburg@posteo.de>
> Cc: martin rudalics <rudalics@gmx.at>, 18722@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 07:46:45 -0700
> 
> > If Emacs doesn't redisplay the changes, then what does "is responding
> > to changes" mean?  How do you even kn ow Emacs responds to changes, if
> > it doesn't redisplay?
> 
> As I said in the original post, correct rendering is resumed when I
> click on a menu and I see that Emacs has in fact updated the buffers
> according to my inputs.  Even before clicking on a menu item I see that
> Emacs processes my input when for example menus change in response to
> inputs: e.g., when I switch buffers, I see different menus at the top
> according to the modes that are active in the respective buffers but the
> windows are not updated.  So it seems that the problem really is
> updating of the window displays.

I'm not sure.  What you see is the result of Emacs updating the
display, but you cannot know whether the changes to buffers according
to your inputs happened while the display was outdated, or immediately
prior to updating the display as result of your clicking.

IOW, it could be that all your inputs are processed in one go when you
click, and the display updated right after that.

Or do you have evidence that the scenario I described did not in fact
happen?

> I'm fairly sure that the problem was introduced by a recent change in
> Emacs because I didn't change anything else at the time when the problem
> first occurred.  Specifically, I did not change the window manager or
> its configuration.

It would be helpful if you could quantify "recent" to the best of your
knowledge and records, if not bisect the trunk.  Thanks in advance.