all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Paddy Mullen'" <paddy@paddymullen.com>, <help-gnu-emacs@gnu.org>
Subject: RE: display-buffer-alist
Date: Sat, 5 Nov 2011 14:24:07 -0700	[thread overview]
Message-ID: <DF94406A9744404D948984D2FD39ACE0@us.oracle.com> (raw)
In-Reply-To: <CAFpY3ue6Mb0A_RK3ZtUL6PhTZUbdZpQspSKS55n3QbLhwr9xXA@mail.gmail.com>

> I'm having a very hard time understanding the documentation
> for display-buffer-alist.

You are not alone. 

> emacs24 behaves differently than emacs23.

Not only differently by default, but perhaps even altogether differently (?).
I'm not even sure you _can_ (easily? at all?) obtain the Emacs 23 behavior using
Emacs 24.  And I'm not sure users will be able to easily understand the
differences.

Fortunately, Emacs 24 has not yet been released.

> Could someone please post the setq command to get emacs 24
> to behave the way I am used to.  something along the lines of
> (setq display-buffer-alist '(??????))

I wish someone could - or rather, to be more optimistic, I hope someone will.
Unfortunately, I cannot.  I'm in the same boat as you, I'm afraid.

Believe it or not, one of the main motivations for the changes was supposedly to
make things simpler!  It was thought that the interactions among the existing
separate user options affecting buffer display, such as
`special-display-regexps' and `pop-up-frames', could confuse users.  (Dunno
whether there were really any user complaints about this - I'm not aware of
any.)

Another motivation was, I believe, to give users (and code) more control over
display details (which window, when, where, etc.).  Whether that mixes well with
the goal of making things simpler is uncertain.

So instead of a few different user options, we now have the single usine-a-gaz
`display-buffer-alist'.  There seem to be enough knobs and dials baked into
`display-buffer-alist' to make its mastery worthy of a doctoral dissertation.

And it's only a start, AFAICT.  There are also changes to various functions and
commands, which can affect existing code.  You've read the doc - you have an
idea what you're up against.

There is not only a documentation problem and perhaps a use complexity problem.
There are also outstanding bugs.  And the behavior seems to be "evolving" (i.e.
volatile) as (some) bugs get fixed and new ones are introduced.  There was a
second redesign (overhaul) a relatively short while back.

How we can find ourselves in _pretest_ phase under these conditions I really
don't know.  I'm just hoping that things will all be fixed and clearly
documented before they throw the release itself over the wall to us lusers.

Maybe in the end we'll all be far happier for all these changes.  For now, I
feel the same as you: Somebody please tell me what incantation to use to get
back the behavior I had in Emacs 23 (22, 21, 20...).

On n'arrete pas le progres...




  reply	other threads:[~2011-11-05 21:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-05 17:36 display-buffer-alist Paddy Mullen
2011-11-05 21:24 ` Drew Adams [this message]
     [not found]   ` <CAFpY3ucfZNYBOPciRZLhJ-8__P=ey-iH1ieJU3Vz0whiehELRA@mail.gmail.com>
2011-11-05 21:44     ` display-buffer-alist Paddy Mullen
2011-11-05 22:47       ` display-buffer-alist Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2015-01-12  1:31 display-buffer-alist Tak Kunihiro
2011-11-06  8:51 display-buffer-alist martin rudalics
2011-11-09 17:52 ` display-buffer-alist Paddy Mullen
2011-11-10  8:22   ` display-buffer-alist martin rudalics
2011-11-10 14:43     ` display-buffer-alist Paddy Mullen
2011-11-05 15:57 display-buffer-alist Paddy Mullen
2011-11-05 18:13 ` display-buffer-alist Paddy Mullen

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

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

  git send-email \
    --in-reply-to=DF94406A9744404D948984D2FD39ACE0@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=paddy@paddymullen.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.