GNU bug report logs -
#8857
display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Mon, 13 Jun 2011 22:22:01 UTC
Severity: normal
Done: David Engster <deng <at> randomsample.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 15 Jun 2011 12:17:17 -0400
with message-id <f3pqmfqdbm.fsf <at> fencepost.gnu.org>
and subject line Re: bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error
has caused the GNU bug report #8857,
regarding display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
8857: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8857
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Package: emacs
With the current trunk:
./src/emacs -Q -batch README INSTALL Makefile
Loading vc-bzr...
Unknown terminal type
(exits with status /= 0)
OK, this is not a very sensible example, but it illustrates the point.
It's caused by display-buffer trying to pop-up a frame in batch-mode and
is very recent.
Emacs 23 does not have this problem by default, but the following shows
the same issue:
emacs-23.3 -Q -batch --eval '(setq pop-up-frames t)' README INSTALL Makefile
[Message part 3 (message/rfc822, inline)]
Stefan Monnier wrote:
> "batch mode" and "server mode" are *very* closely related. So I'd stay
> away from any attempt to special case "batch mode".
martin rudalics wrote:
> There's a silent convention that `display-buffer' _always_ returns a
> window. If it doesn't in batch mode, code relying on that convention
> might break. I don't know how realistic such a scenario is, though.
OK, no problem, let's not bother with it then.
> Meanwhile I checked in two fixes that should assure that
> `display-buffer' doesn't try to pop up a frame with emacs -Q. If they
> work, you should be able to remove your earlier hack.
If you mean the cus-dep thing, then it was a correct change, independent
of this issue, and should remain.
I'll close this, thanks.
This bug report was last modified 14 years and 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.