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

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

[Glenn Morris]

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

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

[Glenn Morris]

PS I forgot to say that I think display-buffer should not try to pop-up
frames (or do anything at all?) in batch-mode. Or if it must give an
error it should try to give a more helpful one than "Unknown terminal
type".

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

[martin rudalics]

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

Can you tell me where and why `display-buffer' is called?

 > PS I forgot to say that I think display-buffer should not try to pop-up
 > frames (or do anything at all?) in batch-mode. Or if it must give an
 > error it should try to give a more helpful one than "Unknown terminal
 > type".

In particular not with emacs -Q.  But I have no experience debugging
emacs with the batch option.  So before delving into this maybe you
could give me more information?

Note that while `pop-up-frames' has the optional value graphic-only
which should prevent Emacs from popping up frames on non-graphic
systems, that value is consistently overridden by applications that bind
`pop-up-frames' to t.  But I don't think that's related.

martin

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

[Glenn Morris]

martin rudalics wrote:

>> 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.
>
> Can you tell me where and why `display-buffer' is called?

I don't know. From `find-file' I guess. I noticed because of this:

http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00004.html

(which was due to custom-make-dependencies leaving files on the
command-line so they were processed as normal file arguments)

>> PS I forgot to say that I think display-buffer should not try to pop-up
>> frames (or do anything at all?) in batch-mode. Or if it must give an
>> error it should try to give a more helpful one than "Unknown terminal
>> type".
>
> In particular not with emacs -Q.  But I have no experience debugging
> emacs with the batch option.  So before delving into this maybe you
> could give me more information?

Maybe display-buffer should just be a no-op in batch-mode, since it's
impossible (?) to display anything then (except via the echo area).

(defun display-buffer () ""
 (unless noninteractive
   ...))

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

[martin rudalics]

 >> Can you tell me where and why `display-buffer' is called?
 >
 > I don't know. From `find-file' I guess. I noticed because of this:
 >
 > http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00004.html
 >
 > (which was due to custom-make-dependencies leaving files on the
 > command-line so they were processed as normal file arguments)

I see.  But I wonder why this wasn't a problem before (that is, the idea
of popping up a new frame).

 > Maybe display-buffer should just be a no-op in batch-mode, since it's
 > impossible (?) to display anything then (except via the echo area).
 >
 > (defun display-buffer () ""
 >  (unless noninteractive
 >    ...))

That would be trivial to do.

martin

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

[Glenn Morris]

martin rudalics wrote:

> But I wonder why this wasn't a problem before (that is, the idea of
> popping up a new frame).

I guess because pop-up-frames defaults to nil in Emacs 23.
But in the trunk, a default Emacs may now pop-up a frame if it thinks it
necessary.

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

[martin rudalics]

 > I guess because pop-up-frames defaults to nil in Emacs 23.

Emacs 23 could pop up new frame provided the selected frame isn't
"usable".

 > But in the trunk, a default Emacs may now pop-up a frame if it thinks it
 > necessary.

I only tried to mimic Emacs 23 here.  So if the original frame cannot be
used it does try to pop up a new one.  Doesn't Emacs make an invisible
frame in batch mode?

Maybe the problem happens because I now load window.el _before_
files.el.  So in Emacs 23 files.el maybe tried to display a buffer but
failed silently.  What happens generally in batch mode when you call
`display-buffer', for example, during a backtrace?

martin

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

[Glenn Morris]

martin rudalics wrote:

>> I guess because pop-up-frames defaults to nil in Emacs 23.
>
> Emacs 23 could pop up new frame provided the selected frame isn't
> "usable".

I confess I did not look into precisely what Emacs 23 does, I just saw
that pop-up-frames defaults to nil there. (See below.)

>> But in the trunk, a default Emacs may now pop-up a frame if it thinks it
>> necessary.
>
> I only tried to mimic Emacs 23 here.  So if the original frame cannot be
> used it does try to pop up a new one.  Doesn't Emacs make an invisible
> frame in batch mode?
>
> Maybe the problem happens because I now load window.el _before_
> files.el.  So in Emacs 23 files.el maybe tried to display a buffer but
> failed silently. 

I don't think that can be it.

Here's what the addition of a simple:

(message "%s:%s" buffer-or-name method)

to display-buffer in the trunk shows:

./src/emacs -Q -batch README INSTALL BUGS

INSTALL:reuse-window
INSTALL:pop-up-window
BUGS:reuse-window
BUGS:pop-up-window
BUGS:pop-up-frame
Unknown terminal type


Adding similar stuff to emacs-23, I see that display-buffer's cond tries
the special-display-function branch (no match), the pop-up-windows
branch (no window-to-use), and ends up in the last branch, where it
finds a window-to-use every time. So it never tries to pop-up a frame.

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

[martin rudalics]

 > Adding similar stuff to emacs-23, I see that display-buffer's cond tries
 > the special-display-function branch (no match), the pop-up-windows
 > branch (no window-to-use), and ends up in the last branch, where it
 > finds a window-to-use every time. So it never tries to pop-up a frame.

Emacs 23 tries to pop up a frame only when the selected frame is a
minibuffer frame.  I shall add an appropriate condition in Emacs 24.

martin

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

[Glenn Morris]

In addition I still think it might be worth explicitly making
display-buffer a no-op in batch mode, unless someone can think of
something it can actually do in such cases. I think this could only be
by side effect. Eg, can it run hooks, and can those hooks be expected to
do anything when there isn't actually a display?

If not then it seems simpler and more efficient to not even try
displaying buffers in batch mode (and less confusing, since it can give
unclear errors trying to do something that cannot work).

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

[martin rudalics]

 > In addition I still think it might be worth explicitly making
 > display-buffer a no-op in batch mode, unless someone can think of
 > something it can actually do in such cases. I think this could only be
 > by side effect. Eg, can it run hooks, and can those hooks be expected to
 > do anything when there isn't actually a display?
 >
 > If not then it seems simpler and more efficient to not even try
 > displaying buffers in batch mode (and less confusing, since it can give
 > unclear errors trying to do something that cannot work).

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.

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.

martin

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

[Stefan Monnier]

> In addition I still think it might be worth explicitly making
> display-buffer a no-op in batch mode, unless someone can think of
> something it can actually do in such cases. I think this could only be

"batch mode" and "server mode" are *very* closely related.  So I'd stay
away from any attempt to special case "batch mode".

At best, you could try and check the currently selected terminal and do
something special when that terminal is the "initial" terminal (the one
bound to stdout/stdin), but I'd rather not obscure the code to
"optimize" this case.


        Stefan

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

[Glenn Morris]

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.

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

[David Engster]

martin rudalics writes:
> 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.

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

-David

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

[martin rudalics]

 > Is this supposed to also fix the problem for batch mode? Because I still
 > see this error with revno. 104589:

It was supposed to fix that, yes.

 >  --> emacs --batch foo bar baz
 > Unknown terminal type

Can you check whether `display-buffer' tries to pop up a new buffer?  I
don't have the slightest experience running Emacs in batch mode.

 > Actually, this currently breaks the CEDET build, because it uses a hack
 > to provide arguments for functions called with the "-f" switch...

Maybe Glenn can tell us what's going on?

martin

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

[Glenn Morris]

martin rudalics wrote:

> Maybe Glenn can tell us what's going on?

Haha, nope, except to point out that you said:

> Meanwhile I checked in two fixes that should assure that
> `display-buffer' doesn't try to pop up a frame with emacs -Q.

whereas the quoted recipe:

>>  --> emacs --batch foo bar baz
>> Unknown terminal type

does not use -Q.

(Therefore I guess it would fail in the same way for anyone using Emacs
23 who happens to have set pop-up-frames = t in their .emacs.)

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

[David Engster]

Glenn Morris writes:
> martin rudalics wrote:
>
>> Maybe Glenn can tell us what's going on?
>
> Haha, nope, except to point out that you said:
>
>> Meanwhile I checked in two fixes that should assure that
>> `display-buffer' doesn't try to pop up a frame with emacs -Q.
>
> whereas the quoted recipe:
>
>>>  --> emacs --batch foo bar baz
>>> Unknown terminal type
>
> does not use -Q.

It also fails with "-Q" (and "--batch" implies "-q", at least).

Cheers,
David

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

[David Engster]

martin rudalics writes:
>> Is this supposed to also fix the problem for batch mode? Because I still
>> see this error with revno. 104589:
>
> It was supposed to fix that, yes.
>
>>  --> emacs --batch foo bar baz
>> Unknown terminal type
>
> Can you check whether `display-buffer' tries to pop up a new buffer?  I
> don't have the slightest experience running Emacs in batch mode.

I don't know if this is what you're looking for, but when I run this:

--> emacs --batch -Q --eval "(debug-on-entry 'display-buffer-pop-up-window)" foo bar baz

I get this:

Debugger entered--entering a function:
  display-buffer-pop-up-window(#<buffer bar> ((largest) (lru)) ((pop-up-frame) (reuse-window other other visible) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (reuse-window other other nil) (reuse-window-even-sizes . t) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (pop-up-frame) (pop-up-frame-alist (height . 24) (width . 80) (unsplittable . t)) (reuse-window nil other visible) (reuse-window-even-sizes . t)))
* display-buffer(#<buffer bar> other-window nil)
  pop-to-buffer(#<buffer bar> other-window nil)
  switch-to-buffer-other-window(#<buffer bar>)
  find-file-other-window("/home/void/bar")
  command-line-1(("--eval" "(debug-on-entry 'display-buffer-pop-up-window)" "foo" "bar" "baz"))
  command-line()
  normal-top-level()

Cheers,
David

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

[Glenn Morris]

David Engster wrote:

> It also fails with "-Q" (and "--batch" implies "-q", at least).

Oh, I forgot that batch implies -q. Yes, it's still trying to pop-up
frames for me too.

./src/emacs -Q -batch BUGS README INSTALL

README:reuse-window
README:pop-up-window
INSTALL:reuse-window
INSTALL:pop-up-window
INSTALL:pop-up-frame
Unknown terminal type

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

[martin rudalics]

 > I don't know if this is what you're looking for, but when I run this:

More or less so, thanks.  Putting the debug-on-entry on
`display-buffer-pop-up-frame' would have been more indicative.

 > --> emacs --batch -Q --eval "(debug-on-entry 'display-buffer-pop-up-window)" foo bar baz
 >
 > I get this:
 >
 > Debugger entered--entering a function:
 >   display-buffer-pop-up-window(#<buffer bar> ((largest) (lru)) ((pop-up-frame) (reuse-window ...
                                                                   ^^^^^^^^^^^^^^

`display-buffer-pop-up-window' likely fails here to produce a window and
next `display-buffer' tries to pop up a new frame.

 > * display-buffer(#<buffer bar> other-window nil)
 >   pop-to-buffer(#<buffer bar> other-window nil)
 >   switch-to-buffer-other-window(#<buffer bar>)
 >   find-file-other-window("/home/void/bar")
 >   command-line-1(("--eval" "(debug-on-entry 'display-buffer-pop-up-window)" "foo" "bar" "baz"))
 >   command-line()
 >   normal-top-level()

The problem is that `switch-to-buffer-other-window' has to use "another"
window.  If it can't pop up a window on the selected frame it tries to
pop up a new frame :-( As Glenn remarked - you can get the same problem
by setting `pop-up-frames' to t.  What shall I do?

martin

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

[Glenn Morris]

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

FWIW, `noninteractive' is nil in "server mode" (ie --daemon) but t in
"batch mode", so the two cases are easily distinguished.

Since emacs.c has:

  if (!noninteractive)
    init_display ();    /* Determine terminal type.  Calls init_sys_modes.  */

I've gone back to thinking that display-buffer can do nothing useful in
batch mode.

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

[David Engster]

martin rudalics writes:
> The problem is that `switch-to-buffer-other-window' has to use "another"
> window.  If it can't pop up a window on the selected frame it tries to
> pop up a new frame :-( As Glenn remarked - you can get the same problem
> by setting `pop-up-frames' to t.  What shall I do?

I'm a bit confused. Yes, Emacs23 shows the same error with pop-up-frames
to 't'. However, if I explicitly set it to 'nil' for Emacs24, I still
get the same error:

--> emacs --batch -Q --eval "(setq pop-up-frames nil)" foo bar baz
Unknown terminal type

If the issue is really just the changed default for `pop-up-frames', I'd
say the default should be again changed to 'graphic-only instead of
'unset.

-David

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

[Stefan Monnier]

>> "batch mode" and "server mode" are *very* closely related.  So I'd stay
>> away from any attempt to special case "batch mode".

> FWIW, `noninteractive' is nil in "server mode" (ie --daemon) but t in
> "batch mode", so the two cases are easily distinguished.

> Since emacs.c has:

>   if (!noninteractive)
>     init_display ();    /* Determine terminal type.  Calls init_sys_modes.  */

> I've gone back to thinking that display-buffer can do nothing useful in
> batch mode.

It might fix it for batch mode, but you may get the same problem in
"server mode before opening any display or tty".  That's what I mean by
the two being closely related.

I.e. we need to make it work on the dummy initial terminal.


        Stefan

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

[Glenn Morris]

Stefan Monnier wrote:

> It might fix it for batch mode, but you may get the same problem in
> "server mode before opening any display or tty".  That's what I mean by
> the two being closely related.
>
> I.e. we need to make it work on the dummy initial terminal.

I'm not so sure, because server mode at least _has_ a dummy terminal.
Can you give an example of server mode running into the same problem as
being discussed for batch mode?

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

[martin rudalics]

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

Thanks, martin

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

[David Engster]

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

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

[martin rudalics]

 > 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

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

[David Engster]

martin rudalics writes:
>> 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'.

I see.

>
>> or it is simply
>> tested with
>>
>> (if pop-up-frames
>>   ...
>
> I can't find this anywhere :-(

Sorry, I should have been more explicit: There are places in the Emacs
sources which only test pop-up-frames for being non-nil, usually with
'and'/'or':

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.

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

OK, I think I understand the motivation behind 'unset now. However, this
effectively means that there really is no default value for
pop-up-frames, 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.

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

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

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

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

Thanks for explaining,
David

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

[Stefan Monnier]

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

graphics-only was a quick fix for people who want to set pop-up-frames
in their .emacs but get annoyed when they tty-emacsclient end up popping
up frames as well.

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

More generally we want to specify different display-buffer behaviors for
tty (where frames are fully-overlapping) and graphic terminals (where
several frames may be visible at the same time).


        Stefan

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

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

[David Engster]

martin rudalics writes:
>> However, this
>> effectively means that there really is no default value for
>> pop-up-frames,
>
> ... well it's 'unset ...

Yes. But I think you understand my problem: 'unset doesn't say whether
you should pop up a new frame by default or not. It's pretty much what
Drew says in #8865, and I tend to agree with him on this issue. I think
this special handling of 'unset is cumbersome, and it should simply be a
boolean variable with a default of nil or t.

Anyway, I don't want to bother you with two threads on the same issue,
and the original problem has been solved, so I'm closing this bug and
will maybe follow-up on #8865, but I think pretty much everything has
been said regarding this issue.

-David