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

[Juanma Barranquero <lekktu@gmail.com>]

On Sun, Jun 20, 2010 at 01:36, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

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

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.

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

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

> 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, or not wanting your
patches, or not wanting to take the trouble to understand, etc. etc.

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

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

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

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

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

Glad to help.

    Juanma