bug#7658: 24.0.50; emacsclient not raising frame

bug#7658: 24.0.50; emacsclient not raising frame

[nyc4bos]

When using emacsclient and eval'ing a function that calls
`select-frame-by-name', the emacs frame is not raised.

To simplify for this bug report, I'm using `select-frame-by-name'
directly (below).

emacsclient -n --eval "(select-frame-by-name \"emacs@system\")"
(I replaced the real system-name with "system").

From the command line I can see:

emacs-24.0.50\bin\emacsclient.exe: connected to remote socket at
xxx.xx.x.xxx

So I can see that it made the connection (I removed the real IP adress)
but the frame is not raised.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-12-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  show-paren-mode: t
  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> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Loading e:/home/.emacs.d/.emacs-custom-24.el (source)...done
Adding e:/home/cygwin to load-path
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow emacsbug debug canlock sha1 hex-util newcomment pp two-column
iso-transl help-mode view gnus-fun mule-util sort gnus-cite smiley
ansi-color mail-extr gnus-bcklg qp re-builder multi-isearch gnus-async
byte-opt bytecomp byte-compile gnus-ml nndraft nnmh nndoc utf-7 nnagent
nnml nnimap utf7 nnfolder parse-time gnus-agent gnus-srvr gnus-score
score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view smime dig
nntp proto-stream starttls tls gnus-cache epa-file epa derived epg
epg-config sieve sieve-mode sieve-manage password-cache nnir gnus-sum
gnus-group mm-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-util url-parse auth-source netrc url-vars
mailcap time-date gnus-undo nnmail mail-source format-spec gnus-start
gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnoo nnheader
gnus-util mm-util mail-prsvr mail-utils help-macro advice advice-preload
pager w3m-search w3m help-fns browse-url doc-view easymenu jka-compr
dired regexp-opt image-mode timezone w3m-hist w3m-fb easy-mmode
bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image w3m-proc w3m-util
wid-edit w3m-wget cl server edmacro kmacro paren tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe 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 button minibuffer
faces cus-face files text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)

bug#7658: 24.0.50; emacsclient not raising frame

[Juanma Barranquero]

On Thu, Dec 16, 2010 at 23:23,  <nyc4bos@aol.com> wrote:

> From the command line I can see:
>
> emacs-24.0.50\bin\emacsclient.exe: connected to remote socket at
> xxx.xx.x.xxx
>
> So I can see that it made the connection (I removed the real IP adress)
> but the frame is not raised.

IIUC, the connection is remote, i.e., you're invoking emacsclient in
one computer, and emacs is running in another one (both Windows, I
suppose).

In that case, there's nothing we can do. The trend on newer Windows is
to give the user, not the programs, the control of the focus, so
programs requesting it do not normally get it.

However, a program that already has the focus can pass the privilege,
so to speak, to another one. When you run emacsclient, it has the
focus. So, it tries to detect a running Emacs in the same computer
with the right pid, and if it finds it, it calls a Windows API,
AllowSetForegroundWindow, to pass it the focus. But obviously this
does not work for a program in a remote computer; not even if one of
the computers is just a virtual machine running in the other one.

    Juanma

bug#7658: 24.0.50; emacsclient not raising frame

[nyc4bos]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Dec 16, 2010 at 23:23,  <nyc4bos@aol.com> wrote:
>
>> From the command line I can see:
>>
>> emacs-24.0.50\bin\emacsclient.exe: connected to remote socket at
>> xxx.xx.x.xxx
>>
>> So I can see that it made the connection (I removed the real IP adress)
>> but the frame is not raised.
>
> IIUC, the connection is remote, i.e., you're invoking emacsclient in
> one computer, and emacs is running in another one (both Windows, I
> suppose).

No, both emacs and emacsclient are invoked on the same Windows computer.

>
> In that case, there's nothing we can do. The trend on newer Windows is
> to give the user, not the programs, the control of the focus, so
> programs requesting it do not normally get it.
>
> However, a program that already has the focus can pass the privilege,
> so to speak, to another one. When you run emacsclient, it has the
> focus. So, it tries to detect a running Emacs in the same computer
> with the right pid, and if it finds it, it calls a Windows API,
> AllowSetForegroundWindow, to pass it the focus. But obviously this
> does not work for a program in a remote computer; not even if one of
> the computers is just a virtual machine running in the other one.

Thanks for this information.

A virtual machine is not involved.

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

Thanks.


>
>     Juanma

bug#7658: 24.0.50; emacsclient not raising frame

[Juanma Barranquero]

On Thu, Jul 7, 2011 at 01:03,  <nyc4bos@aol.com> wrote:

> No, both emacs and emacsclient are invoked on the same Windows computer.

And you have it set up to use other than the default 127.0.0.1? Why?
So it can accept both local and remote connections?

> A virtual machine is not involved.

I wasn't suggesting that, it was just an example.

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

How are you invoking emacsclient?

    Juanma

bug#7658: 24.0.50; emacsclient not raising frame

[Juanma Barranquero]

Do you still see the bug in the newest pretest or trunk?

    Juanma

bug#7658: 24.0.50; emacsclient not raising frame

[nyc4bos]

Juanma Barranquero <lekktu@gmail.com> writes:

> Do you still see the bug in the newest pretest or trunk?

Not sure when it happened and what was the bugfix, but this is
now fixed in the Emacs 24.1 released and later versions.

Thanks!

>
>     Juanma

bug#7658: 24.0.50; emacsclient not raising frame

[Juanma Barranquero]

> Not sure when it happened and what was the bugfix, but this is
> now fixed in the Emacs 24.1 released and later versions.

OK, I'm closing this bug. Please reopen if you see the same problem again.

    Juanma

bug#10034: 24.0.91; max-specpdl-size error

[nyc4bos]

I was playing around with built-in GnuTLS and the funtions
`open-gnutls-stream' and `gnutls-negotiate' to try to get
trustfiles to work on Windows. (GnuTLS doesn't support a "-CApath"
option where you can specify a directory where PEM files lives,
unfortunately, unlike OpenSSL).

I would create a GnuTLS process via:

(with-temp-buffer
(open-gnutls-stream "tls" "tls-buffer" "imap.aim.com" 993))

and

(gnutls-negotiate :process (open-network-stream "tls" "tls-buffer"
                     "imap.aim.com" 993)
                    :type 'gnutls-x509pki
                    :trustfiles trustfiles
                    :hostname host)


When I didn't see a successful verification message, i.e. warnings:

gnutls.c: [1] (Emacs) certificate signer was not found: imap.aim.com

I would kill the "tls-buffer" (hence killing the GnuTLS process) and
the buffer would be killed and I would see the expected message:

gnutls.c: [2] (Emacs) Deallocating x509 credentials

I would then make modifications to the definition of `trustfiles' or
PEM files, etc. and try again.

I would do this iteration many times.

Eventually, I would get into a state where I couldn't do much, seeing
messages like:

window-min-size-1: Variable binding depth exceeds max-specpdl-size

I then could only kill Emacs.


In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
 of 2011-11-07 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags -I"D:/devel/emacs/libs/libXpm-3.5.8/include" -I"D:/devel/emacs/libs/libXpm-3.5.8/src" -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" -I"D:/devel/emacs/libs/giflib-4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" -I"D:/devel/emacs/libs/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags -L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: cp949
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  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:
<return> n <return> C-x b * M e <tab> <return> C-r 
g n u t C-a C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-v C-s C-s <help-echo> <help-echo> <help-echo> 
<help-echo> C-x b * s c <tab> C-g <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_record.c:918

gnutls.c: [2] (Emacs) Deallocating x509 credentials
gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_buffers.c:601

gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_record.c:918

gnutls.c: [2] (Emacs) Deallocating x509 credentials
Mark saved where search started
xding
Quit

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message derived format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev nnheader mail-utils gmm-utils mailheader emacsbug
network-stream auth-source eieio byte-opt bytecomp byte-compile cconv
macroexp assoc gnus-util mm-util mail-prsvr password-cache starttls tls
gnutls advice advice-preload pager w3m-search w3m help-fns browse-url
doc-view easymenu jka-compr dired desktop regexp-opt image-mode timezone
w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image
w3m-proc w3m-util wid-edit w3m-wget server easy-mmode cl edmacro kmacro
paren time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image
fringe 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 files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#10034: 24.0.91; max-specpdl-size error

[martin rudalics]

 > Eventually, I would get into a state where I couldn't do much, seeing
 > messages like:
 >
 > window-min-size-1: Variable binding depth exceeds max-specpdl-size
 >
 > I then could only kill Emacs.

Do you mean that Emacs looped and C-g didn't quit?  If you can see a
message like the above, C-g usually works.

 > In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
 >  of 2011-11-07 on MARVIN

IIUC this is with a build made _before_ Chong's `window-total-size'
change, so the latter can't be the culprit.

I can't propose much about this at the moment.  If this happens again
and you can get back to the command loop via C-g, try to open a new
frame via C-x 5 2 and look at the last lines of the *Messages* buffer.
If for some reason you can't make a new frame, try C-x 1 instead.

martin

bug#7658: 24.0.50; emacsclient not raising frame

[nyc4bos]

Juanma Barranquero <lekktu@gmail.com> writes:

> Do you still see the bug in the newest pretest or trunk?

Yes, I still see the bug with the latest trunk version:

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


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