From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.bugs Subject: bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error Date: Thu, 16 Jun 2011 15:57:24 +0200 Message-ID: References: <4DF726E0.6020205@gmx.at> <4DF79707.7000707@gmx.at> <4DF7A0D0.2030707@gmx.at> <4DF7B1D2.3010304@gmx.at> <9ypqmfy2lo.fsf@fencepost.gnu.org> <4DF866F7.3070006@gmx.at> <87oc1zkp0n.fsf@engster.org> <4DF9CBA1.1090307@gmx.at> <4DF9FE9D.3080609@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308235291 19882 80.91.229.12 (16 Jun 2011 14:41:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2011 14:41:31 +0000 (UTC) Cc: 8857@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 16 16:41:26 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QXDl6-0000xU-N5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jun 2011 16:41:24 +0200 Original-Received: from localhost ([::1]:42494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXDl5-0006RY-Dx for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jun 2011 10:41:23 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXD5F-0003Tp-3F for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:58:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXD59-0003G0-Jq for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:58:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXD59-0003Fn-5K for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QXD58-00020d-98; Thu, 16 Jun 2011 09:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Engster Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jun 2011 13:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8857 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8857-submit@debbugs.gnu.org id=B8857.13082326607693 (code B ref 8857); Thu, 16 Jun 2011 13:58:02 +0000 Original-Received: (at 8857) by debbugs.gnu.org; 16 Jun 2011 13:57:40 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QXD4l-000202-3L for submit@debbugs.gnu.org; Thu, 16 Jun 2011 09:57:39 -0400 Original-Received: from v3-1008.vxen.de ([79.140.41.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QXD4i-0001zo-C7 for 8857@debbugs.gnu.org; Thu, 16 Jun 2011 09:57:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=SFmrP6DGrHyTRpTiHdqu92l38OUVKaxtU5c9/le4JPw=; b=aKH1E8UcKf3fMZClwVfTstBtC4ugBjIwv8nljdncBjiFYYzqdb7hoaq7s4dfP2YGOdlDdkSxh5Q+h3jF9C8QWu8pXL2z1yuExSFqJRMii2DJEfz9qv6OqCemMH04t8jo; Original-Received: from ibookg4-c2.pc.gwdg.de ([134.76.4.219]) by v3-1008.vxen.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QXD4c-00087e-C0; Thu, 16 Jun 2011 15:57:30 +0200 In-Reply-To: <4DF9FE9D.3080609@gmx.at> (martin rudalics's message of "Thu, 16 Jun 2011 15:01:17 +0200") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (darwin) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 16 Jun 2011 09:58:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:47235 Archived-At: martin rudalics writes: >> BTW, but I think related to this, I don't really understand the new >> default for pop-up-frames. The doc-string says: >> >> "If this is the symbol unset, the option was not set and is >> ignored." > > 'unset stands for "nobody bothered to set or bind this". > >> Sorry, but I think this is a bit of a cop-out. You can't really ignore a >> boolean option - you either pop up a new frame or you don't; it all just >> depends on how you handle "unset", and this introduces ambiguity in the >> code. A quick grep shows me that pop-up-frames is either tested with >> >> (if (memq pop-up-frames '(nil unset)) >> ... >> >> which means 'unset is actually handled as "not set", > > Because it's the same for `display-buffer'. I see. > >> or it is simply >> tested with >> >> (if pop-up-frames >> ... > > I can't find this anywhere :-( Sorry, I should have been more explicit: There are places in the Emacs sources which only test pop-up-frames for being non-nil, usually with 'and'/'or': calendar/diary-lib.el: (let* ((pop-up-frames (or pop-up-frames (window-dedicated-p (selected-window)))) mail/rmail.el: (and pop-up-frames (one-window-p)) progmodes/inf-lisp.el: (let ((pop-up-frames ;; Be willing to use another frame ;; that already has the window in it. (or pop-up-frames (get-buffer-window inferior-lisp-buffer t)))) vc/pcvs-util.el: (let ((pop-up-windows (or pop-up-windows pop-up-frames)) ... just to mention a few. >> which means 'unset is handled as "set". > > But an application should be allowed to test whether the user or the > calling application has set this option in some way or the other before > possibly (re-)binding it. If the value is still 'unset, no one bothered > about it. If it is nil, someone up there explicitly doesn't want to pop > up buffers. If it's graphic-only, someone up there wants to pop them up > on graphic systems only. Any other value means that someone wants to > pop up frames anywhere. Not that applications care that much ... OK, I think I understand the motivation behind 'unset now. However, this effectively means that there really is no default value for pop-up-frames, and every application can decide how they will deal with that. The snippets above will see it as non-nil and will now create frames. >> I would vote for setting the default to 'graphic-only. > > IIRC the default was nil. 'graphic-only was IMHO a not very > well-conceived idea because it didn't inhibit applications to rebind > this to t. I've never seen a `pop-up-frames' rebinding function care > about this issue. Right, the current code doesn't care about 'graphic-only, but neither does the old code care about 'unset. This can be changed, of course... :-) >> (Maybe this is the wrong place to discuss this - please let me know if I >> should file another bug-report or bring this to emacs-devel). > > Please do what you find more convenient ;-) > > BTW, Drew started a related discussion in another thread. I asked him > to join us. I actually don't feel that strongly about it. It just found it confusing, but I think I understand it better now. I have set this option to nil anyway. :-) Thanks for explaining, David