Subject: Re: bug#6468: A couple of problem related to frame raising (partly w32)

From: Lennart Borgman <[email-masked]>
Date: Sun, 20 Jun 2010 14:21:25 +0200

On Sun, Jun 20, 2010 at 3:07 AM, Lennart Borgman
<[email-masked]> wrote:
>>
>> Are you sure this isn't just Windows trying to keep Emacs from
>> stealing the focus? You know, AllowSetForegroundWindow and that stuff.
>> I've sometimes seen emacsclient call Emacs from a console (4NT) and
>> Emacs not getting the focus because 4NT (and so emacsclient) just
>> happened to lose the focus before calling AllowSetForegroundWindow.
>
>
> No, I am not sure. And since the frame seems to be in a strange state
> I am even more unsure. "Was there some bad system call that made the
> OS upset so it refuses to do this?"
>
> I have seen such problem when dealing with low level functions. It can
> be very frustrating. Maybe a lot of those bugs in Windows that led to
> bad recovery now have been cured. I have know idea and it can really
> take a long time to find out.
>
> I thought first when you mention AllowSetForegroundWindow "ah, that is
> Firefox that does not give emacsclient this so it can't give it to
> Emacs". But that can not be the case since if I server-raise-frame is
> non-nil then Emacs comes to the foreground (but the whole of it, not
> just the frame I want).
>
> And then I have been looking at which threads was involved. At least
> it looks like the same threads. But maybe still there is an issue with
> the threads that I do not understand. Perhaps only one thread has this
> privelege and it is not given to the other? There is no transferring
> of it in Emacs AFAICS.

It happened again that it worked. Ah, fine, I thought and removed what
I commented out. Then it stopped working.

Any thoughts about what could be behind why Emacs behaves this way?
What do you think we should do?

My own guess is that there are some bad system calls in Emacs
somewhere that causes Emacs to fail. But I am not sure where. From my
own experiences I know that they do not have to be around the calls to
SetForegroundWindow at all. Since both you and Eli thinks that it is a
bad idea to check more system calls I would be glad for a suggestion
what to do instead.