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

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

[Lennart Borgman]

After struggling with the getting raise-frame to workaround the
current problems with raise-frame I gave up. There are a couple of
problems so I am not sure where to begin.

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.

But I tried to do the raise-frame in a hook to and that does not work
either in all situations and I am not quite sure why.

One problem is that the system API calls currently is not checked and
partly in bad order. Here is the relevant part from w32fns.c:

    case WM_EMACS_SETFOREGROUND:
      {
        HWND foreground_window;
        DWORD foreground_thread, retval;

        /* On NT 5.0, and apparently Windows 98, it is necessary to
           attach to the thread that currently has focus in order to
           pull the focus away from it.  */
        foreground_window = GetForegroundWindow ();
	foreground_thread = GetWindowThreadProcessId (foreground_window, NULL);
        if (!foreground_window
            || foreground_thread == GetCurrentThreadId ()
            || !AttachThreadInput (GetCurrentThreadId (),
                                   foreground_thread, TRUE))
          foreground_thread = 0;

        retval = SetForegroundWindow ((HWND) wParam);

        /* Detach from the previous foreground thread.  */
        if (foreground_thread)
          AttachThreadInput (GetCurrentThreadId (),
                             foreground_thread, FALSE);

        return retval;
      }

The first call to GetWindowThreadProcessId should not be done if the
call to GetForegroundWindow does not succeed.

If there had been error checking this problem should have been
detected long ago. I have suggested adding that but the answer so far
has not been positive. In my opinion this is a huge waste of time. (I
can surely add this to my patched version but in the current situation
where I unfortunately have to keep a lot of bug fixes in my code it
costs my just too much time.)

Next problem is that if foreground_window is not 0 then the value of
foreground_thread will be erased if do not misunderstand the C
priorities. Can someone please confirm/disconfirm this?

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

[Juanma Barranquero]

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

> If there had been error checking this problem should have been
> detected long ago. I have suggested adding that but the answer so far
> has not been positive.

You suggest littering the w32 sources with DebPrint calls (or ugly
macro-equivalents). The thing to do is, now that you've found a case
where not checking the result value is a bug, to fix the bug.

Yes, adding lots of DebPrint would perhaps help to find such bugs; or
perhaps it would generate so many useless warnings that would make it
even harder... There has been no deluge of bug reports related to
unchecked w32 syscalls that I am aware of.

    Juanma

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

[Lennart Borgman]

On Sat, Jun 19, 2010 at 8:35 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sat, Jun 19, 2010 at 20:23, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> If there had been error checking this problem should have been
>> detected long ago. I have suggested adding that but the answer so far
>> has not been positive.
>
> You suggest littering the w32 sources with DebPrint calls (or ugly
> macro-equivalents). The thing to do is, now that you've found a case
> where not checking the result value is a bug, to fix the bug.
>
> Yes, adding lots of DebPrint would perhaps help to find such bugs; or
> perhaps it would generate so many useless warnings that would make it
> even harder... There has been no deluge of bug reports related to
> unchecked w32 syscalls that I am aware of.

I found this problem after adding the ugly macro-equivalent.

And yes, the thing now is to try to fix it. But there are several
things missing and I am a bit hesitating to address the problem since
it costs me so much time discussing it. I can't afford that cost.

However if you want to comment on the bad nesting here I would be
glad. Do I misread it?

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

[Juanma Barranquero]

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

> I found this problem after adding the ugly macro-equivalent.

It is called "debugging". Thanks for you work on this bug.

> And yes, the thing now is to try to fix it. But there are several
> things missing and I am a bit hesitating to address the problem since
> it costs me so much time discussing it. I can't afford that cost.

You seem to think that other people on these discusions have all the
time of the world. Often, if you gave all the details, as precise as
possible, from the beginning, everyone involved (including yourself)
would save time. If you propose a change and it is not accepted
because the interested parties do not understand what problem you're
experiencing or cannot reproduce it because you have not provided
detail enough to convince them that there is indeed a problem and your
fix is sound... well, then, who's wasting who's time?

> However if you want to comment on the bad nesting here I would be
> glad. Do I misread it?

I cannot comment. I don't see a reproducible recipe and a clear
description in your report.

    Juanma

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

[Lennart Borgman]

On Sat, Jun 19, 2010 at 9:20 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
> You seem to think that other people on these discusions have all the
> time of the world. Often, if you gave all the details, as precise as
> possible, from the beginning, everyone involved (including yourself)
> would save time.

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

> If you propose a change and it is not accepted
> because the interested parties do not understand what problem you're
> experiencing or cannot reproduce it because you have not provided
> detail enough to convince them that there is indeed a problem and your
> fix is sound... well, then, who's wasting who's time?

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

What do you want me to do then?

>> However if you want to comment on the bad nesting here I would be
>> glad. Do I misread it?
>
> I cannot comment. I don't see a reproducible recipe and a clear
> description in your report.

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

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?


>    Juanma
>

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

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

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 19 Jun 2010 20:23:29 +0200
> Cc: 
> 
> After struggling with the getting raise-frame to workaround the
> current problems with raise-frame I gave up. There are a couple of
> problems so I am not sure where to begin.

Would you please describe the problem(s) you are talking about?

How about a reproducible recipe for them?

TIA

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
>

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

[Juanma Barranquero]

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

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

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

[Lennart Borgman]

On Sun, Jun 20, 2010 at 3:07 AM, Lennart Borgman
<lennart.borgman@gmail.com> 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.

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

[Lennart Borgman]

On Sun, Jun 20, 2010 at 1:36 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
>>> 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.)

Eh, now wait a minute again... - does not that mean that if
foreground_window is not 0 then the "|| foreground_thread =
GetCurrentThread ()" will be executed? (As I said...)

And I do not think that is supposed to happen. Or do I get something wrong here?

Why is it so easy to get this simple thing wrong? (I think I know the
answer, but it hurts my feeling as a human being. We are supposed to
be the most logical animal.)

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

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

[Juanma Barranquero]

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

> Eh, now wait a minute again... - does not that mean that if
> foreground_window is not 0 then the "|| foreground_thread =
> GetCurrentThread ()" will be executed? (As I said...)

There's no

  || foreground_thread = GetCurrentThreadId ()

on the code you quoted; there is

  || foreground_thread == GetCurrentThreadId ()

which is not the same thing. No assignment in sight there.

    Juanma

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

[Lennart Borgman]

On Tue, Jun 22, 2010 at 10:17 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 01:19, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> Eh, now wait a minute again... - does not that mean that if
>> foreground_window is not 0 then the "|| foreground_thread =
>> GetCurrentThread ()" will be executed? (As I said...)
>
> There's no
>
>  || foreground_thread = GetCurrentThreadId ()
>
> on the code you quoted; there is
>
>  || foreground_thread == GetCurrentThreadId ()
>
> which is not the same thing. No assignment in sight there.


You are right. Then it is perhaps only a logical error (which likely
is a typo) since my version I have here now works.

Could you please write it any way you like it? (Maybe turn the test
around to the recommended order so people like me who read C very
seldom don't get fooled?)

Just a comment: It is a bit surprising that no one have seen it
before. Maybe people just did not expect this to work in Emacs? (I
remember I saw this once before but misread it and did not have time
to come back to it.)

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

[Juanma Barranquero]

On Tue, Jun 22, 2010 at 12:39, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> You are right. Then it is perhaps only a logical error (which likely
> is a typo) since my version I have here now works.

Lennart, I haven't looked at the source code, just the example you
sent. What logical error? Are you saying that the comparation is an
error, or that the real Emacs code contains an assignment and that is
an error, or what?

> Could you please write it any way you like it?

No, I'm not likely to touch code in complex parts of Emacs I don't really know.

> (Maybe turn the test
> around to the recommended order so people like me who read C very
> seldom don't get fooled?)

People who read little C should learn more C before trying to change
the Emacs sources, IMNSHO.

    Juanma

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

[Lennart Borgman]

On Tue, Jun 22, 2010 at 12:58 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 12:39, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> You are right. Then it is perhaps only a logical error (which likely
>> is a typo) since my version I have here now works.
>
> Lennart, I haven't looked at the source code, just the example you
> sent. What logical error? Are you saying that the comparation is an
> error, or that the real Emacs code contains an assignment and that is
> an error, or what?
>
>> Could you please write it any way you like it?
>
> No, I'm not likely to touch code in complex parts of Emacs I don't really know.
>
>> (Maybe turn the test
>> around to the recommended order so people like me who read C very
>> seldom don't get fooled?)
>
> People who read little C should learn more C before trying to change
> the Emacs sources, IMNSHO.


Isn't it more important to understand the logic before trying to
change anything?

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

[Juanma Barranquero]

On Wed, Jun 23, 2010 at 12:17, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Isn't it more important to understand the logic before trying to
> change anything?

Isn't necessary to learn the language before trying to understand the logic?

    Juanma

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

[Lennart Borgman]

On Wed, Jun 23, 2010 at 12:34 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 12:17, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> Isn't it more important to understand the logic before trying to
>> change anything?
>
> Isn't necessary to learn the language before trying to understand the logic?

I don't think that it is necessary. It is just easier, but not necessary.

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

[Juanma Barranquero]

On Wed, Jun 23, 2010 at 12:41, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I don't think that it is necessary. It is just easier, but not necessary.

Mistakes will be funny to watch.

    Juanma

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

[Lennart Borgman]

On Wed, Jun 23, 2010 at 12:54 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 12:41, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> I don't think that it is necessary. It is just easier, but not necessary.
>
> Mistakes will be funny to watch.


I just get a bit frustrated when I see the mistakes here.

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

[Glenn Morris]

tags 6468 notabug
stop

Eli Zaretskii wrote:

> Would you please describe the problem(s) you are talking about?
>
> How about a reproducible recipe for them?

This was never answered.

This isn't a bug a report, just a rambling discussion that goes nowhere.

If there is a problem, open a new, self-contained report that actually
gives details.

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

[Lennart Borgman]

I prefer to give up. If it is enough to call it rant then I have no
one to eplain to. And I have no time to waste on such answers.


On Thu, Oct 6, 2011 at 22:36, GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
> Your bug report
>
> #6468: A couple of problem related to frame raising (partly w32)
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 6468@debbugs.gnu.org.
>
> --
> 6468: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6468
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Glenn Morris <rgm@gnu.org>
> To: 6468-done@debbugs.gnu.org
> Date: Thu, 06 Oct 2011 16:35:24 -0400
> Subject: Re: bug#6468: A couple of problem related to frame raising (partly w32)
> tags 6468 notabug
> stop
>
> Eli Zaretskii wrote:
>
>> Would you please describe the problem(s) you are talking about?
>>
>> How about a reproducible recipe for them?
>
> This was never answered.
>
> This isn't a bug a report, just a rambling discussion that goes nowhere.
>
> If there is a problem, open a new, self-contained report that actually
> gives details.
>
>
>
> ---------- Forwarded message ----------
> From: Lennart Borgman <lennart.borgman@gmail.com>
> To: Emacs Bugs <bug-gnu-emacs@gnu.org>
> Date: Sat, 19 Jun 2010 20:23:29 +0200
> Subject: A couple of problem related to frame raising (partly w32)
> After struggling with the getting raise-frame to workaround the
> current problems with raise-frame I gave up. There are a couple of
> problems so I am not sure where to begin.
>
> 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.
>
> But I tried to do the raise-frame in a hook to and that does not work
> either in all situations and I am not quite sure why.
>
> One problem is that the system API calls currently is not checked and
> partly in bad order. Here is the relevant part from w32fns.c:
>
>    case WM_EMACS_SETFOREGROUND:
>      {
>        HWND foreground_window;
>        DWORD foreground_thread, retval;
>
>        /* On NT 5.0, and apparently Windows 98, it is necessary to
>           attach to the thread that currently has focus in order to
>           pull the focus away from it.  */
>        foreground_window = GetForegroundWindow ();
>        foreground_thread = GetWindowThreadProcessId (foreground_window, NULL);
>        if (!foreground_window
>            || foreground_thread == GetCurrentThreadId ()
>            || !AttachThreadInput (GetCurrentThreadId (),
>                                   foreground_thread, TRUE))
>          foreground_thread = 0;
>
>        retval = SetForegroundWindow ((HWND) wParam);
>
>        /* Detach from the previous foreground thread.  */
>        if (foreground_thread)
>          AttachThreadInput (GetCurrentThreadId (),
>                             foreground_thread, FALSE);
>
>        return retval;
>      }
>
> The first call to GetWindowThreadProcessId should not be done if the
> call to GetForegroundWindow does not succeed.
>
> If there had been error checking this problem should have been
> detected long ago. I have suggested adding that but the answer so far
> has not been positive. In my opinion this is a huge waste of time. (I
> can surely add this to my patched version but in the current situation
> where I unfortunately have to keep a lot of bug fixes in my code it
> costs my just too much time.)
>
> Next problem is that if foreground_window is not 0 then the value of
> foreground_thread will be erased if do not misunderstand the C
> priorities. Can someone please confirm/disconfirm this?
>
>
>
>