* [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
@ 2006-06-28 17:25 Richard Stallman
2006-07-04 20:16 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2006-06-28 17:25 UTC (permalink / raw
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 -------
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-06-28 17:25 [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display] Richard Stallman
@ 2006-07-04 20:16 ` Chong Yidong
2006-07-04 21:04 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2006-07-04 20:16 UTC (permalink / raw
Cc: Stefan Monnier
> $ /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)))
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-07-04 20:16 ` Chong Yidong
@ 2006-07-04 21:04 ` Stefan Monnier
2006-07-05 13:17 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2006-07-04 21:04 UTC (permalink / raw
Cc: emacs-devel
> ***************
> *** 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-07-04 21:04 ` Stefan Monnier
@ 2006-07-05 13:17 ` Chong Yidong
2006-07-06 22:14 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2006-07-05 13:17 UTC (permalink / raw
Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-07-05 13:17 ` Chong Yidong
@ 2006-07-06 22:14 ` Stefan Monnier
2006-07-06 22:49 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2006-07-06 22:14 UTC (permalink / raw
Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-07-06 22:14 ` Stefan Monnier
@ 2006-07-06 22:49 ` Chong Yidong
2006-07-07 15:21 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2006-07-06 22:49 UTC (permalink / raw
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display]
2006-07-06 22:49 ` Chong Yidong
@ 2006-07-07 15:21 ` Stefan Monnier
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2006-07-07 15:21 UTC (permalink / raw
Cc: emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-07-07 15:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-28 17:25 [ottomaddox@fastmail.fm: emacsclient won't open new frame on remote display] Richard Stallman
2006-07-04 20:16 ` Chong Yidong
2006-07-04 21:04 ` Stefan Monnier
2006-07-05 13:17 ` Chong Yidong
2006-07-06 22:14 ` Stefan Monnier
2006-07-06 22:49 ` Chong Yidong
2006-07-07 15:21 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).