[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8857: display-buffer attempt to pop-up frame in batch mode causes "U

From: martin rudalics
Subject: bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error
Date: Thu, 16 Jun 2011 15:01:17 +0200
User-agent: Thunderbird (Windows/20090302)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]