GNU bug report logs - #8857
display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error

Previous Next

Full log

Message #82 received at 8857 <at> debbugs.gnu.org (full text, mbox):

From: David Engster <deng <at> randomsample.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Glenn Morris <rgm <at> gnu.org>, 8857 <at> debbugs.gnu.org
Subject: Re: bug#8857: display-buffer attempt to pop-up frame in batch mode
	causes	"Unknown terminal type" error
Date: Thu, 16 Jun 2011 12:04:15 +0200

martin rudalics writes:
>> Is this supposed to also fix the problem for batch mode? Because I still
>> see this error with revno. 104589:
>>
>>  --> emacs --batch foo bar baz
>> Unknown terminal type
>>
>> Actually, this currently breaks the CEDET build, because it uses a hack
>> to provide arguments for functions called with the "-f" switch...
>
> My earlier fix wasn't rigid enough.  Please try again.

Works for me. Thanks!

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."

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", or it is simply
tested with

(if pop-up-frames
  ...

which means 'unset is handled as "set".

I would vote for setting the default to 'graphic-only.

(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).

-David

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.