unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: David Engster <deng@randomsample.de>
Cc: 8857@debbugs.gnu.org
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	[thread overview]
Message-ID: <4DF9FE9D.3080609@gmx.at> (raw)
In-Reply-To: <m27h8may8w.fsf@ibookg4-c2.pc.gwdg.de>

 > 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






  reply	other threads:[~2011-06-16 13:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13 22:21 bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error Glenn Morris
2011-06-13 22:23 ` Glenn Morris
2011-06-14  9:16   ` martin rudalics
2011-06-14 16:19     ` Glenn Morris
2011-06-14 17:14       ` martin rudalics
2011-06-14 17:20         ` Glenn Morris
2011-06-14 17:56           ` martin rudalics
2011-06-14 18:25             ` Glenn Morris
2011-06-14 19:09               ` martin rudalics
2011-06-15  7:29                 ` Glenn Morris
2011-06-15  8:01                   ` martin rudalics
2011-06-15 16:17                     ` Glenn Morris
2011-06-15 17:01                     ` David Engster
2011-06-15 17:45                       ` martin rudalics
2011-06-15 18:09                         ` Glenn Morris
2011-06-15 18:13                           ` David Engster
2011-06-15 19:16                             ` Glenn Morris
2011-06-15 18:30                         ` David Engster
2011-06-15 19:32                           ` martin rudalics
2011-06-15 19:42                             ` David Engster
2011-06-16  9:23                       ` martin rudalics
2011-06-16 10:04                         ` David Engster
2011-06-16 13:01                           ` martin rudalics [this message]
2011-06-16 13:57                             ` David Engster
2011-06-16 15:08                               ` martin rudalics
2011-06-17  6:49                                 ` David Engster
2011-06-16 14:17                             ` Stefan Monnier
2011-06-15 14:36                   ` Stefan Monnier
2011-06-15 19:40                     ` Glenn Morris
2011-06-15 21:02                       ` Stefan Monnier
2011-06-15 22:13                         ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF9FE9D.3080609@gmx.at \
    --to=rudalics@gmx.at \
    --cc=8857@debbugs.gnu.org \
    --cc=deng@randomsample.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).