bug#13094: Problem with emacsclient not raising frame is back -- regression

[Eli Zaretskii]

> From: nyc4bos@aol.com
> Cc: 13094@debbugs.gnu.org,  Juanma Barranquero <lekktu@gmail.com>, Eli 
> Zaretskii <eliz@gnu.org>
> Date: Tue, 29 Jan 2013 15:50:16 -0500
> 
> 0. On MS Windows open up at least one application so that you have
>    at least one Window on the screen.
> 1. C:\emacs-24.2.92\bin\runemacs.exe -Q
> 
>    When the Emacs frame appears, position it so that it is on top
>    of the an application you previously opened.
> 
> 2. M-x server-start
> 3. Iconify Emacs
> 4. From a MS Windows command prompt, type the following (on one line):
> 
>   C:\emacs-24.3.50\bin\emacsclient.exe -n
>       --eval "(select-frame-by-name \"emacs@<SYSTEM>\")"
> 
>   where <SYSTEM> is your system name so that NAME matches the name of
>   the Emacs titlebar.
> 
>   Emacs should now be deiconified, at the forefront (raised), and ready
>   for input.
> 
> 5. Click on the MS Window command prompt and execute step 4 again
> 
> You should then notice that Emacs does NOT come to the forefront (top-most
> raised Window) but that the MS Windows command prompt Window is still
> selected after step 4.
> 
> You should also see that the Gnu Emacs (tile?) at the bottom of the screen
> "blinks" but the Emacs frame is not raised and selected.

Thanks.  Now I understand the problem and its reason(s).

> [FWIW, if I use the emacsclient.exe from Lennart's patched version:
> 
> GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600) of 2009-11-03 on LENNART-69DE564 
> (patched)
> 
> against the latest Gnu Emacs pretest available to me (Bzr revision: 111199)
> or the trunk version (Bzr revision 111604), it works as expected.]

This is not really relevant: Lennart's emacsclient is such a different
beast in how it launches Emacs that it is impossible to reason about
this issue from what that emacsclient does or doesn't do.  So let's
forget about this part of the puzzle.

My analysis of this is that it has nothing to do with emacsclient per
se, and neither is it a regression since Emacs 24.1: I see the same
behavior in stock 24.1 on 2 different Windows machines.  (It _is_ a
regression from Emacs 23.3, though.)  So the old bug reports where you
reported similar problems sound unrelated to this one, if indeed they
were resolved (of which I'm not sure).

The reason for this problem is that raise-frame on Windows does not
raise the frame to the top of z-order, in this particular use case.
It just gives that frame input focus (which you can see if you make
the cursor of the Emacs frame visible before running the emacsclient
command the 2nd time: you will see the cursor starts blinking).  To
see that raise-frame is th culprit, modify your recipe like this,
after step 4:

4.1. Type into the *scratch* buffer:

  (defun raise-frame-by-name (name)
    ""
    (let* ((frame-names-alist (make-frame-names-alist))
           (frame (cdr (assoc name frame-names-alist))))
      (when frame
        (message "Raising %s..." frame)
        (raise-frame frame))))

4.2  Evaluate this function.

4.3  Click on the Command Prompt window to make it the foreground
window.  Then move the Command Prompt window on display so that the
echo area of the Emacs's frame is visible.

5. Execute the following command from the Command Prompt window:

   C:\emacs-24.3.50\bin\emacsclient.exe -n
       --eval "(raise-frame-by-name \"emacs@<SYSTEM>\")"

You will see the "Raising" message in the echo area of Emacs, but the
frame will not come to the forefront.

Doing the same in Emacs 23.3 does bring the frame to the forefront.

Conclusion: emacsclient does its job by telling Emacs to invoke
raise-frame, and Emacs does.  But raise-frame does not produce the
expected effect.

I believe this change in behavior since 23.3 is a side effect of
fixing another bug:

 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11513

That change fixed a similar, but evidently distinct aspect of
raise-frame's behavior.  We could try reverting that change, but then
there will be another user who will claim that a bug solved long ago
"is back".

It would be nice to solve this problem without un-fixing the other
one.  But for this, Someone(TM) who knows much more than I do about
Windows GUI should step forward and show us how to do that.  We don't
have such a knowledgeable person on board at this time, unfortunately.

As a temporary workaround, you could customize w32-grab-focus-on-raise
to nil; my testing indicates that you will have the behavior you want
then.