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

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

[nyc4bos]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

Hi,

It appears that the problem with Emacs not raising the frame which I
originally reported (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7658)
is back.

It was fixed sometime after this release of Emacs:

GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-06 on MARVIN

and Sun, 26 Aug 2012 22:13:07 -0400 when Juanma 

However, the problem (below) is now back (at least on Windows 7 professional):

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7658#11

"The Emacs tile (at the bottom of the screen) turns orange for a few
seconds but the Emacs instance (frame) does not come to the forefront
if it is already deiconified.

However, if it is iconified, emacsclient (calling `select-frame-by-name')
does deiconify it, as expected.

So the problem appears to be when it is deiconified and then calling
`select-frame-by-name'."


This problem is also present in the trunk bzr r111077

Thanks.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
e:/emacs-24.2.90/etc/DEBUG.


In GNU Emacs 24.2.90.1 (i386-mingw-nt6.1.7601)
 of 2012-12-03 on MS-W7-DANI
Bzr revision: 110985 lekktu@gmail.com-20121203014526-h8k6xh4fk7b2qhc8
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'

Important settings:
  value of $LANG: en_US
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32 multi-tty
emacs)

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

[nyc4bos]

Hi,

There appears to be a regression in terms of this bug using the
latest branch version available for MS Windows (24.2.91, bzr 111040):


In GNU Emacs 24.2.91.1 (i386-mingw-nt6.1.7601)
 of 2012-12-15 on MS-W7-DANI
Bzr revision: 111040 cyd@gnu.org-20121215141602-c4qmr11gc39rrpng
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'


As also specified originally in bug#7658 which was fixed:

     http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7658#20

I am able to use a version of emacsclient.exe that works with
GNU Emacs 24.2.91.1 pretest which I also wrote in that bug report:

[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 emacs.exe trunk version, it works as expected.]


So it would appear that since bug#7658 was fixed, a change in
emacsclient.exe since then has manifested this problem again.

It would be great if this problem were to be fixed before the next
version of GNU Emacs 24.3 were released.

Thanks.

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

[Chong Yidong]

nyc4bos@aol.com writes:

> There appears to be a regression in terms of this bug using the
> latest branch version available for MS Windows (24.2.91, bzr 111040):

Could you bisect to find the commit which caused this problem to occur?
Thanks.

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

[nyc4bos]

Chong Yidong <cyd@gnu.org> writes:

> nyc4bos@aol.com writes:
>
>> There appears to be a regression in terms of this bug using the
>> latest branch version available for MS Windows (24.2.91, bzr 111040):
>
> Could you bisect to find the commit which caused this problem to occur?

I only have the provided Windows binaries.

I'll see if I can hunt them down and see which Bzr version first
exhibited the regression.

(FWIW, emacsclient.exe from Lennart's patch version against Gnu Emacs
Bzr revision: 111393 works just fine.)

GNU Emacs 23.1.50.1 (i386-mingw-nt6.1.7601) of 2009-11-03 on
LENNART-69DE564 (patched)

Thanks.

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

[nyc4bos]

Hi,

Eli asked for a clear reproducible recipe not referenced in older reports:

http://lists.gnu.org/archive/html/emacs-devel/2013-01/msg00627.html

So here is the clear recipe consolidated in this bug report:

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.


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

Thanks.

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.

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

[nyc4bos]

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.