From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Does display-buffer display the buffer or not? Date: Fri, 24 Dec 2010 11:22:41 +0100 Message-ID: <8739pnbhce.fsf@member.fsf.org> References: <87r5d7bn8s.fsf@member.fsf.org> <4D14688E.4090606@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1293186190 5937 80.91.229.12 (24 Dec 2010 10:23:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 24 Dec 2010 10:23:10 +0000 (UTC) Cc: Lennart Borgman , Emacs-Devel devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 24 11:23:06 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PW4nh-0002np-0z for ged-emacs-devel@m.gmane.org; Fri, 24 Dec 2010 11:23:05 +0100 Original-Received: from localhost ([127.0.0.1]:55028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PW4nf-0003Ei-OS for ged-emacs-devel@m.gmane.org; Fri, 24 Dec 2010 05:23:03 -0500 Original-Received: from [140.186.70.92] (port=52917 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PW4nN-0003DX-Bq for emacs-devel@gnu.org; Fri, 24 Dec 2010 05:22:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PW4nL-0002rh-RT for emacs-devel@gnu.org; Fri, 24 Dec 2010 05:22:45 -0500 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:13419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PW4nL-0002rQ-Fv for emacs-devel@gnu.org; Fri, 24 Dec 2010 05:22:43 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 58E97780169E; Fri, 24 Dec 2010 11:22:42 +0100 (CET) Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27435-03; Fri, 24 Dec 2010 11:22:41 +0100 (CET) X-CHKRCPT: Envelopesender noch tassilo@member.fsf.org Original-Received: from thinkpad (tsdh.uni-koblenz.de [141.26.67.142]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 551D9780169C; Fri, 24 Dec 2010 11:22:41 +0100 (CET) In-Reply-To: <4D14688E.4090606@gmx.at> (martin rudalics's message of "Fri, 24 Dec 2010 10:31:58 +0100") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-Virus-Scanned: amavisd-new at uni-koblenz.de X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133935 Archived-At: martin rudalics writes: Hi Martin, >> My first idea was that when you say NOT-THIS-WINDOW (t) and the >> current FRAME (nil), but the current frame has only one window and is >> only of minimal size, so no split can be done, then it must return >> nil and do nothing. Unfortunately, testing that situation with >> >> (display-buffer "*info*" t nil) >> >> pops up a completely new frame showing *info*. Reading the docs a bit >> further, there is >> >> ,----[ C-h f display-buffer RET ] >> | [...] >> | >> | nil - consider windows on the selected frame (actually the >> | last non-minibuffer frame) only. If, however, either >> | `display-buffer-reuse-frames' or `pop-up-frames' is non-nil >> | (non-nil and not graphic-only on a text-only terminal), >> | consider all visible or iconified frames. >> `---- >> >> Unfortunately, both `display-buffer-reuse-frames' and `pop-up-frames' >> are nil, here. >> >> I do think that creating a new frame is appropriate in the situation >> above, but the docs should make that clear. Currently, they don't match >> the implemented behavior. > > The Elisp manual says > > If all options described above fail to produce a suitable window, > `display-buffer' tries to reuse an existing window. As a last resort, > it will try to display BUFFER-OR-NAME on a separate frame. In that > case, the value of `pop-up-frames' is disregarded. Ok, I see. > I never investigated whether this occurs in practice and what happens, > for example, on non-graphic displays. In ttys it also creates a new frame with that buffer. You cannot see that there is a new frame, except that you have to to C-x 5 0 twice to return to the command line (when tty frame was created by emacsclient) or to get the message that one cannot delete the only frame (with emacs -nw -Q), and (frames-on-display-list) returns 2 frames. Hm, is it sensible to have multiple frames on one tty? You can only see one at a time anyway... > It's just a fallback method and I'm not sure whether it's worth > mentioning in the doc-string. Yes, IMO, it is. And the "nil if no such window is found" should be removed. The fallback ensures that a window will always be found, right? With the current spelling, I read the docs like "the function caller should check that the return-value of display-buffer is nil, and if it is, act appropriately by creating a new frame, for example." Bye, Tassilo