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

[martin rudalics <rudalics@gmx.at>]

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

I replaced most of these in my window-pub branch which, however, doesn't
care about 'unset value yet.  Obviously, all of these don't DTRT in
Emacs 23 when a user has set `pop-up-frames' to 'graphic-only and is on
a non-graphic system.

 > OK, I think I understand the motivation behind 'unset now.

'unset was a quick fix to make old code work with the new
`display-buffer'.  There might be some yet unknown quirks in it.  Maybe
I even don't need it.

 > However, this
 > effectively means that there really is no default value for
 > pop-up-frames,

... well it's 'unset ...

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

Yes.  Just as they wrongly handled 'graphic-only in Emacs 23.

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

This must be changed, of course :-)

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

Me too.  That's why I'm not very familiar with the ensuing problems.

martin