unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>
Cc: 8865@debbugs.gnu.org
Subject: bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'
Date: Thu, 16 Jun 2011 17:08:27 +0200	[thread overview]
Message-ID: <4DFA1C6B.50400@gmx.at> (raw)
In-Reply-To: <E335A9462F414DEE92C07919BC4E2FAD@us.oracle.com>

 > How about looking at the Emacs sources before you made your changes? ;-)  If you
 > grep the Emacs 20, 21, 22, or 23 Lisp source code for `pop-up-frames' you will
 > see lots of hits, some of which are tests of its value.  For example (Emacs
 > 23.3):
 >
 >>From help.el:
 > (cond ((or pop-up-frames...)...)
 > ...

All these tests will be removed/replaced in due time because these
variables are obsolete now.

 > I use such tests in only a couple of places.  They are of course based on the
 > (original) meaning of `pop-up-frames': non-nil means `display-buffer' uses a
 > separate frame.

And that was incorrect already in Emacs 23.  The value 'graphic-only
should have been dealt with separately.

 > Nothing special.
 >
 > So the question is how to test that user intention using the latest Emacs
 > design.  From my code:
 >
 > ;; If non-nil `pop-up-frames' then inhibit showing annotation.
 > (let ((bookmark-automatically-show-annotations
 >        (and bookmark-automatically-show-annotations
 >             (not pop-up-frames))))
 >
 > ;; Use separate frames instead of windows if `pop-up-frames'
 > ;; is non-nil or if prefix arg is negative.
 > (cond (...)
 >       ((or pop-up-frames option)
 >        (while file-list (find-file-other-frame...

Code shouldn't try to guess the user's intentions in the first place:
The strategy, in increasing priority, is

- users express their intentions in `display-buffer-alist',

- the code can suggest a better solution by passing a second argument to
   the buffer display function,

- users can override the code by setting the override specifier in
   `display-buffer-alist'.

Code should only express suggestions in the sense that "displaying the
buffer in this or that way is best to my knowledge".  The user can
accept that suggestion or override it.  In most cases, however, code
should not suggest anything and leave the decision to the user.

Obviously, if your code is targeted only at users not customizing
`display-buffer-alist', you can test `pop-up-frames' as before, taking
care of the special values 'unset (which means the user doesn't bother)
and 'graphic-only.  One benefit of this is that if `pop-up-frames' is
nil, the user has explicitly delared that she doesn't want to pop up new
frames with your code.

martin





  reply	other threads:[~2011-06-16 15:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 18:14 bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' Drew Adams
2011-06-14 19:08 ` martin rudalics
2011-06-14 19:43   ` Drew Adams
2011-06-15  9:24     ` martin rudalics
2011-06-15 16:14       ` Drew Adams
2011-06-15 16:26         ` martin rudalics
2011-06-15 17:11           ` Drew Adams
2011-06-15 17:44             ` martin rudalics
2011-06-15 17:53               ` Drew Adams
2011-06-15 22:15                 ` Drew Adams
2011-06-16 13:01                   ` martin rudalics
2011-06-16 14:01                     ` Drew Adams
2011-06-16 15:08                       ` martin rudalics [this message]
2011-06-16 16:03                         ` Drew Adams
2011-06-17 15:46                           ` martin rudalics
2011-06-17 18:31                             ` Drew Adams
2011-06-19 17:43                               ` Drew Adams
2011-06-19 18:50                                 ` martin rudalics
2011-06-19 20:13                                 ` Drew Adams
2011-06-16 13:09                   ` Stefan Monnier
2011-06-16 14:02                     ` Drew Adams
2011-06-17  2:44                       ` Stefan Monnier
2011-06-17 15:08                         ` Drew Adams
2011-06-17 16:21                           ` Stefan Monnier
2011-06-17 18:31                             ` Drew Adams
2011-06-17 21:46                               ` Stefan Monnier
2011-06-17 23:55                                 ` Drew Adams
2011-06-18  1:51                                   ` Stefan Monnier
2011-06-16  8:45               ` martin rudalics

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=4DFA1C6B.50400@gmx.at \
    --to=rudalics@gmx.at \
    --cc=8865@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /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).