RE: display-buffer-alist

[Paddy Mullen <paddy@paddymullen.com>]

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

I don't know what any single incantation should look like.  Do you mind
sharing what you have tried so that I can fool around with it some myself.

On Nov 5, 2011 5:24 PM, "Drew Adams" <drew.adams@oracle.com> wrote:
>
> > 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...
>

[-- Attachment #2: Type: text/html, Size: 3480 bytes --]