From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: gnu/emacs client --create-frame somehow? Date: Tue, 02 Dec 2003 23:44:47 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <87u14pdbck.fsf@herrrossi.mmweg.rwth-aachen.de> <87ptf8by0w.fsf@herrrossi.mmweg.rwth-aachen.de> <87ekvmzx9w.fsf@herrrossi.mmweg.rwth-aachen.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070413128 20091 80.91.224.253 (3 Dec 2003 00:58:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2003 00:58:48 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 03 01:58:45 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARLLp-0005JT-00 for ; Wed, 03 Dec 2003 01:58:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARMJD-0006Hx-Su for geh-help-gnu-emacs@m.gmane.org; Tue, 02 Dec 2003 21:00:07 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.24.42 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1070408687 132.204.24.42 (Tue, 02 Dec 2003 18:44:47 EST) Original-NNTP-Posting-Date: Tue, 02 Dec 2003 18:44:47 EST Original-Xref: shelby.stanford.edu gnu.emacs.help:118928 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:14871 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:14871 > gnuserv-visible-frame-function on the other hand is frame > oriented. If there is no frame on my virtual screen, one pops up, > even if the file is already displayed in another buffer. You mean it will reuse a pre-existing window and change the buffer displayed in that window ? In that case indeed, pop-to-buffer might not be what you want, but I don't understand when a frame is going to be opened, then, unless you're thinking of a multiple-X-server situation, in which case the --display argument of emacsclient should be what you want (although it's only be lightly tested). Or do you mean that if the buffer is already displayed in a window but on another display, then pop-to-buffer fails to open a new window/frame on the right display ? That might be: there are many such bugs in a multiple-display situation. Please report such problems to gnu.emacs.bug via M-x report-emacs-bug. > (defun my-xemacs-info-other-frame () > "my-xemacs-info-other-frame" > (interactive) > (let (gnuserv-frame) > (info))) > I can call gnuclient -eval "(my-xemacs-info-other-frame)" and a > frame pops up even if *INFO* is displayed in another frame. But I can't easily check what the above code does: are you trying to force the creation of a new frame that shows the same *info* buffer a second time on the same display or is it on a separate display ? Stefan