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

[Lennart Borgman]

On Sun, Jun 20, 2010 at 1:58 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
> IMHO, sometimes you fail to explain the problem to such a point that
> it is difficult for other people to know whether they have also
> experienced it.

Thanks, I will try to be a bit more careful.

> I don't think Eli's knowledge is limited to the "internals of redisplay".

I never said that.

>> I think both of us has tried the best we can but we have got stuck at
>> this moment.
>
> That, I can understand. What I do not understand is that then you
> switch to accusing people of wasting your time,

I think both Eli and I were beginning to think that time was wasted. I
because I thought that Eli did not look into my patch, but just
assumed it was the wrong thing to do. (I did find that very
irritating. And I think that is quite right of me to not accept that
without any good reason. We are all here without any obligation, but
that means respect is very necessary.)

And Eli maybe because he thought he did not get the data he needed
(which I did believe I sent to him, but I might have missed it).

> or not wanting your
> patches, or not wanting to take the trouble to understand, etc. etc.

The patches are a trouble for me. Merging sometimes take a lot of
time. However without them I (and I think many others) have trouble
using Emacs.

>> 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.
>
> Oh, it can be of help if it makes you think that perhaps (not
> necessarily, but perhaps) he's on the right track and you are not.
> I've seen him ask you, twice, to try something after reverting one of
> your patches, and I don't think you obliged.

I did not try it because I was very sure it should not solve the
problem. That was confirmed when others did try.

What should I do in situations like that?

>> (What happens below is expected. Either you have seen those kind of
>> problems or not. It looks like you have not.
>
> No. But I don't try to do the things you do with frames, mainly
> because I very rarely use more than one.
>
>> For me this is just a
>> normal progress of the discussion. Is it not that for you?)
>
> Seems like a non sequitur. What is a normal progress of the discussion?

Maybe it is a non sequitur. I do not know because I do not know what it is ;-)

Of course normal progression of a discussion can look in many ways. I
just wanted to show how I normal try to get someones attention to a
not so common and maybe therefore not so easy to grasp problem.

>> 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.
>
> All of this seems like a recipe that you *could* send to this thread.
> "Look, I tried with this code here, run in such-and-such
> circumstances, and sometimes it works, sometimes it doesn't". It would
> be clearer than trying to extract meaning from descriptions and
> paraphrases.


Yes, but for me this seems easier, but it depends on whom I am
communicating with. If it is someone I know does not understand elisp
or the functions very well I ask for code. Otherwise I ask for a
description like this.

It makes communication very much faster.


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


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

I have done this mistake before ... ;-)