From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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:01:17 +0200 Message-ID: <4DF9FE9D.3080609@gmx.at> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1308232000 30272 80.91.229.12 (16 Jun 2011 13:46:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2011 13:46:40 +0000 (UTC) Cc: 8857@debbugs.gnu.org To: David Engster Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 16 15:46:31 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 1QXCtz-0006dI-5W for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jun 2011 15:46:31 +0200 Original-Received: from localhost ([::1]:33866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCtx-0000LH-Jy for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Jun 2011 09:46:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCd9-000405-O2 for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:29:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXCd5-0004Xg-78 for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:29:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXCd4-0004XP-Ji for bug-gnu-emacs@gnu.org; Thu, 16 Jun 2011 09:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QXCd3-0000Tn-MO; Thu, 16 Jun 2011 09:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics 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:29:01 +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.13082308921780 (code B ref 8857); Thu, 16 Jun 2011 13:29:01 +0000 Original-Received: (at 8857) by debbugs.gnu.org; 16 Jun 2011 13:28:12 +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 1QXCcG-0000Sd-4y for submit@debbugs.gnu.org; Thu, 16 Jun 2011 09:28:12 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QXCcC-0000SQ-Om for 8857@debbugs.gnu.org; Thu, 16 Jun 2011 09:28:10 -0400 Original-Received: (qmail invoked by alias); 16 Jun 2011 13:01:21 -0000 Original-Received: from 62-47-41-3.adsl.highway.telekom.at (EHLO [62.47.41.3]) [62.47.41.3] by mail.gmx.net (mp060) with SMTP; 16 Jun 2011 15:01:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19g0MkItGtgNECZNidL/KkuXeqAE+2/dP4JF2FeSO cJQEBuhESH2Jvg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 16 Jun 2011 09:29:01 -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:47231 Archived-At: > 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'. > or it is simply > tested with > > (if pop-up-frames > ... I can't find this anywhere :-( > 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 ... > 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. Personally, I'd prefer such an option to affect the behavior of the frame creation functions rather than that of display-buffer. But I don't recall the reason that lead to the introduction of graphic-only. In any case, we could conceive an additional variable (not necessarily an option), say `display-buffer-pop-up-frame-graphic-only', which, if non-nil, effectively inhibits popping up a new frame on non-graphic systems, overriding any value calculated from buffer display specifiers and `pop-up-frames'. > (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. martin