[ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: "Otto Maddox" <ottomaddox@fastmail.fm>
To: emacs-pretest-bug@gnu.org
Content-Disposition: inline
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
Date: Mon, 26 Jun 2006 17:22:28 +0100
Subject: emacsclient won't open new frame on remote display
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

$ /usr/local/emacs/bin/emacs -Q &
M-x server-start

Go to a new xterm window and do this:
$ ssh -X localhost
$ emacsclient --display=$DISPLAY some-file

The buffer for some-file is opened, but not in a new frame and is not
displayed in any existing window.

*Messages* now has this:

Loading server...done
error in process filter: server-process-filter: Attempt to delete the sole visible or iconified frame
error in process filter: Attempt to delete the sole visible or iconified frame

There is a connection to the display:

(x-display-list)
=> (":0.0" "localhost:11.0")

But even though no apparent frame was opened, I cannot close the X
connection:

(x-close-connection "localhost:11.0")
=> (error "Display still has frames on it")

In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.6.0, X toolkit)
 of 2006-06-26
X server distributor `The XFree86 Project, Inc', version 11.0.40400000
configured using `configure '--prefix=/usr/local/emacs/' '--with-x' '--without-carbon' '--with-x-toolkit=athena''

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: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<options> <blink-cursor-mode> <escape> x s e r v <tab> 
s t <tab> <return> <switch-frame> C-x C-b C-x o <down> 
<down> <return> M-x r e p o <tab> r <tab> <return>

Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
Blink-Cursor mode disabled
Loading server...done
error in process filter: server-process-filter: Attempt to delete the sole visible or iconified frame
error in process filter: Attempt to delete the sole visible or iconified frame
Making completion list...
Loading help-mode...done
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done

- -- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Chong Yidong]

> $ /usr/local/emacs/bin/emacs -Q &
> M-x server-start
>
> Go to a new xterm window and do this:
> $ ssh -X localhost
> $ emacsclient --display=$DISPLAY some-file
>
> The buffer for some-file is opened, but not in a new frame and is not
> displayed in any existing window.
>
> There is a connection to the display:
>
> (x-display-list)
> => (":0.0" "localhost:11.0")
>
> But even though no apparent frame was opened, I cannot close the X
> connection:
>
> (x-close-connection "localhost:11.0")
> => (error "Display still has frames on it")

I'm not sure what the relevant code in server.el, which activates when
there is no current frame on the required display, is trying to do.
What I'd naively expect should happen is to try to open a new frame on
the display, like in the patch below.

Probably there's some reason it doesn't do this?  Since Stefan wrote
this code, he probably knows what's going on here.

*** emacs/lisp/server.el.~1.112.~	2006-07-04 13:35:40.000000000 -0400
--- emacs/lisp/server.el	2006-07-04 16:11:17.000000000 -0400
***************
*** 207,220 ****
      ;; and select it.
      (unless (equal (frame-parameter (selected-frame) 'display) display)
        (select-frame
!        (make-frame-on-display
! 	display
! 	;; This frame is only there in place of an actual "current display"
! 	;; setting, so we want it to be as unobtrusive as possible.  That's
! 	;; what the invisibility is for.  The minibuffer setting is so that
! 	;; we don't end up displaying a buffer in it (which noone would
! 	;; notice).
! 	'((visibility . nil) (minibuffer . only)))))))
  
  (defun server-unquote-arg (arg)
    (replace-regexp-in-string
--- 207,213 ----
      ;; and select it.
      (unless (equal (frame-parameter (selected-frame) 'display) display)
        (select-frame
!        (make-frame-on-display display)))))
  
  (defun server-unquote-arg (arg)
    (replace-regexp-in-string
***************
*** 382,390 ****
  	  (run-hooks 'server-switch-hook)
  	  (unless nowait
  	    (message "%s" (substitute-command-keys
! 		      "When done with a buffer, type \\[server-edit]")))))
!       ;; Avoid preserving the connection after the last real frame is deleted.
!       (if tmp-frame (delete-frame tmp-frame))))
    ;; Save for later any partial line that remains.
    (when (> (length string) 0)
      (process-put proc 'previous-string string)))
--- 375,381 ----
  	  (run-hooks 'server-switch-hook)
  	  (unless nowait
  	    (message "%s" (substitute-command-keys
! 		      "When done with a buffer, type \\[server-edit]")))))))
    ;; Save for later any partial line that remains.
    (when (> (length string) 0)
      (process-put proc 'previous-string string)))

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Stefan Monnier]

> ***************
> *** 207,220 ****
>       ;; and select it.
>       (unless (equal (frame-parameter (selected-frame) 'display) display)
>         (select-frame
> !        (make-frame-on-display
> ! 	display
> ! 	;; This frame is only there in place of an actual "current display"
> ! 	;; setting, so we want it to be as unobtrusive as possible.  That's
> ! 	;; what the invisibility is for.  The minibuffer setting is so that
> ! 	;; we don't end up displaying a buffer in it (which noone would
> ! 	;; notice).
> ! 	'((visibility . nil) (minibuffer . only)))))))
  
>   (defun server-unquote-arg (arg)
>     (replace-regexp-in-string
> --- 207,213 ----
>       ;; and select it.
>       (unless (equal (frame-parameter (selected-frame) 'display) display)
>         (select-frame
> !        (make-frame-on-display display)))))
  
>   (defun server-unquote-arg (arg)
>     (replace-regexp-in-string

This suggested change causes Emacs to create a new frame displaying some
random buffer.  If server.el subsequently uses switch-to-buffer or something
like that, it's probably OK, but if it instead uses something like
pop-to-buffer because you want to display emacsclient buffers in their own
window or frame, then you end up with 2 windows (or frames) one of which
displays some random buffer.


        Stefan

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Chong Yidong]

> This suggested change causes Emacs to create a new frame displaying some
> random buffer.  If server.el subsequently uses switch-to-buffer or something
> like that, it's probably OK, but if it instead uses something like
> pop-to-buffer because you want to display emacsclient buffers in their own
> window or frame, then you end up with 2 windows (or frames) one of which
> displays some random buffer.

As the original bug report indicates, the current default behavior is
that the buffer is not displayed at all, which is clearly broken.  My
thinking is that it makes more sense to create the new frame, to
ensure that the default behavior (with no customizations) works.  If
the user customizes the emacsserver behavior, like changing it to use
pop-to-buffer, those personal customizations can be adapted to work
with extra displays.  But the default behavior must definitely work.

What do you think?

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Stefan Monnier]

>> This suggested change causes Emacs to create a new frame displaying some
>> random buffer.  If server.el subsequently uses switch-to-buffer or something
>> like that, it's probably OK, but if it instead uses something like
>> pop-to-buffer because you want to display emacsclient buffers in their own
>> window or frame, then you end up with 2 windows (or frames) one of which
>> displays some random buffer.

> As the original bug report indicates, the current default behavior is
> that the buffer is not displayed at all, which is clearly broken.  My
> thinking is that it makes more sense to create the new frame, to
> ensure that the default behavior (with no customizations) works.  If
> the user customizes the emacsserver behavior, like changing it to use
> pop-to-buffer, those personal customizations can be adapted to work
> with extra displays.  But the default behavior must definitely work.

> What do you think?

The OP's problem is indeed clearly a bug.  I was just pointing out why your
patch is not a good fix.


        Stefan

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> This suggested change causes Emacs to create a new frame displaying some
>>> random buffer.  If server.el subsequently uses switch-to-buffer or something
>>> like that, it's probably OK, but if it instead uses something like
>>> pop-to-buffer because you want to display emacsclient buffers in their own
>>> window or frame, then you end up with 2 windows (or frames) one of which
>>> displays some random buffer.
>
>> As the original bug report indicates, the current default behavior is
>> that the buffer is not displayed at all, which is clearly broken.  My
>> thinking is that it makes more sense to create the new frame, to
>> ensure that the default behavior (with no customizations) works.  If
>> the user customizes the emacsserver behavior, like changing it to use
>> pop-to-buffer, those personal customizations can be adapted to work
>> with extra displays.  But the default behavior must definitely work.
>
>> What do you think?
>
> The OP's problem is indeed clearly a bug.  I was just pointing out why your
> patch is not a good fix.

I've checked in a fix that I think addresses your objection.

Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]

[Stefan Monnier]

>>> As the original bug report indicates, the current default behavior is
>>> that the buffer is not displayed at all, which is clearly broken.  My
>>> thinking is that it makes more sense to create the new frame, to
>>> ensure that the default behavior (with no customizations) works.  If
>>> the user customizes the emacsserver behavior, like changing it to use
>>> pop-to-buffer, those personal customizations can be adapted to work
>>> with extra displays.  But the default behavior must definitely work.
>> 
>>> What do you think?
>> 
>> The OP's problem is indeed clearly a bug.  I was just pointing out why your
>> patch is not a good fix.

> I've checked in a fix that I think addresses your objection.

Thanks.  I haven't had the time to test it yet, but it looks good.


        Stefan