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

[martin rudalics]

> 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