On 2014-10-16 Thu 08:34, Eli Zaretskii wrote:
>> From: Titus von der Malsburg <malsburg@posteo.de>
>> Cc: rudalics@gmx.at, 18722@debbugs.gnu.org
>> Date: Thu, 16 Oct 2014 08:10:37 -0700
>> 
>> I can enter text and save the buffer before clicking menu items.  When I
>> inspect the content of the file with another editor, I see that it
>> contains the text that I entered before saving.
>
> Do you see the changes in the file before or after you click on the
> Emacs frame?  If before, then indeed it sounds like Emacs is reacting
> to your inputs, but the display is not refreshed.

Of course I checked the file before clicking on a menu items,
otherwise the test would not be informative.

> But a situation where Emacs acts on your input, but does not update
> the display is inconceivable, unless some external factor is at work.
> That's because the same loop where Emacs reads input also calls
> redisplay, and since saving a buffer displays a message in the echo
> area, calling redisplay must have updated at least the echo area.  I
> cannot understand how could Emacs save a buffer, but not display the
> echo area message that is part of saving that buffer.

I don't know enough about the inner workings of Emacs to say anything
useful about this but one possibility might be that there is a bug in
GTK that is triggered by recent versions of Emacs but not by earlier
versions.

>> Given on how rarely I update to the latest development version of Emacs,
>> I can't say anything more precise than that the problem was introduced
>> during this summer.  I know, not very helpful.
>
> Do you still have the previous binary you built?  Can you run it now
> and make sure the problem does not exist in that binary?

Unfortunately, I don't have this binary anymore.

>> What do you mean with bisect?  Checkout earlier versions and test them
>> until I find the bad commit?  Given the high volume of commits in Emacs
>> this would take quite a while even when using an efficient
>> search strategy.
>
> Both bzr and git have a bisect command that will converge on the
> offending revision logarithmically.  Since there were about 1000
> commits since the beginning of the summer, you will need about 10
> different builds.

Ok, I'll see what I can do.

  Titus