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

[nyc4bos@aol.com]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

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

Thanks for your thorough analysis aand explanation.

Yes, this temporary workaround raises the frame.

Unfortunatly, it doesn't also gain focus like when it starts out
being iconified and then the command is invoked, at least not for me.