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

[Juanma Barranquero]

On Sat, Jun 19, 2010 at 22:32, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I often do not have them. It is mostly not that kind of problem I am 
> reporting.

Then don't be surprised if other people, who does not see the problem,
have even more trouble understanding what you're talking about.

> Some problems, like the "jumping scrolling" seems hard to understand
> though I have given all logically necessary details.

Of course not. When you say that, and someone who knows a lot more
than you about redisplay (Eli) asks you for clarification, the
principle of parsimony suggests that either you have *not* given all
logically necessary details, or you have *failed* at transmiting that
information.

> What do you want me to do then?

Explain things again, more clearly, and help those that try to help
you, instead of resorting to complains about people wasting your time.

> I have no recipe. I asked about the code. Was that unclear in some
> way? Please explain why then.

I tend not to understand your messages very well. Let's start with this:

"I think the basic problem is that there is no hook so you can be sure
when a call to raise-frame (and other frame functions) will work after
frame creation. Since part of the frame creation as I understand it is
done asynchronously be the OS/window manager I think this is a really
basic need to get Emacs to work."

What does mean "get Emacs to work"? Emacs works, and quite well. Are
you trying to say that not having some hook causes *you* trouble in
some intended application? If so, could you please post an example of
what you intend to do, and why is it not working?

> I am asking about this part:
>
>       foreground_window = GetForegroundWindow ();
>       foreground_thread = GetWindowThreadProcessId (foreground_window, NULL);
>       if (!foreground_window
>           || foreground_thread == GetCurrentThreadId ()
>
> Does not the if clause mean that if foreground_wind is not 0 then the
> old value of foreground_thread will be erased? Or am I misreading
> this?

If foreground_window is 0, or
   foreground_thread is equal to the current thread's id, or
   the AttachThread call returns 0
then
   foreground_thread is set to 0

    Juanma