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

[Lennart Borgman]

On Sat, Jun 19, 2010 at 10:50 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> 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.

I am never surprised by that. When I am telling about a complicated
problem I am merely asking for a starting point in the discussion.
Have others seen similar problems? Do they have any guesses? Have they
tried to investigate some part of the problem?

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


I seldom look into redisplay internals so I hope Eli knows it better.
(I have done it a couple of times looking at certain bugs but I have
not taken it up here I think.)

This is not about the internals of redisplay. It is about the logic
between narrow_to_region etc and redisplay.


>> 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 think both of us has tried the best we can but we have got stuck at
this moment.

I am saying that the best way to solve the problem is to think in
those tracks I have described. I think Eli believes this is wrong.
(And I think Eli believe what I am saying about the original problem
is wrong.)

Perhaps it would be good if someone from outside came in and tried to
understand. But it does not help if you say that Eli understands the
problem better. I am sure Eli understands the display engine better
now, but it is only partly involved. (However understanding of it is
anyway essential of course. I have tried to ask Eli relevant questions
about the display engine.)


>> 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 happens below is expected. Either you have seen those kind of
problems or not. It looks like you have not. For me this is just a
normal progress of the discussion. Is it not that for you?)


> What does mean "get Emacs to work"?


I thought I wrote that in the paragraph above the one you cite but I
have a real bad habit of not reading what I have written before
sending.

I have been trying to get a frame to become the foreground window in a
certain situation but so far failed. There are many things involved so
I am not sure of why it fails. And it does not always fail. I even
believed I found out how to get it to work but after that it has
always failed.

I have tried the normal things like raise-frame,
set-frame-select-input-focus, make-frame-visible, redisplay. And I
have tried to do it in a timer. (I think when it worked I had a rather
large timeout in the timer.)

When doing some logging I have seen that the frame setup does not seem
to be finished. The frame is created, the buffer I want to display is
somehow tied to the frame, but it does not yet have a window. I have
no idea whether this is a part of the problem I have or not.

I do think the process (i.e. Emacs) has enough privileges in my case,
but I am not sure how that kind of privilege works now since it was a
long time ago I looked into that problem and MS tend to change things
for this particular problem (to try to stop evil programs).


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

Example?

I try to open a new frame to edit a text area in Firefox using It's
All Text. This calls emacsclient without wait (since otherwise it
hangs Firefox).

I have set server-raise-frame to nil since I want to create a special
frame for editing and just raise that. If server-raise-frame is
non-nil this will raise the current frame in Emacs instead.

So now in server-window I just create a frame and try to raise that.
And I can't get it to work.

I have a variable pointing to the frame and it looks ok so I know it is there.


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


Ah, shit. Thanks. (I am too unused to reading C code.)


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