From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paddy Mullen Newsgroups: gmane.emacs.help Subject: RE: display-buffer-alist Date: Sat, 5 Nov 2011 17:44:45 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf307f3630e159f804b103ba39 X-Trace: dough.gmane.org 1320529499 9748 80.91.229.12 (5 Nov 2011 21:44:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2011 21:44:59 +0000 (UTC) To: "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Nov 05 22:44:56 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RMo2o-0008DU-2E for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Nov 2011 22:44:54 +0100 Original-Received: from localhost ([::1]:33060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMo2n-0000zT-DA for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Nov 2011 17:44:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMo2i-0000zD-4v for help-gnu-emacs@gnu.org; Sat, 05 Nov 2011 17:44:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMo2g-0005A6-Kw for help-gnu-emacs@gnu.org; Sat, 05 Nov 2011 17:44:48 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:39524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMo2g-00059x-FI for help-gnu-emacs@gnu.org; Sat, 05 Nov 2011 17:44:46 -0400 Original-Received: by vws16 with SMTP id 16so1515vws.0 for ; Sat, 05 Nov 2011 14:44:45 -0700 (PDT) Original-Received: by 10.52.91.5 with SMTP id ca5mr21083645vdb.9.1320529485191; Sat, 05 Nov 2011 14:44:45 -0700 (PDT) Original-Received: by 10.52.186.42 with HTTP; Sat, 5 Nov 2011 14:44:45 -0700 (PDT) X-Originating-IP: [97.60.160.165] Original-Received: by 10.52.186.42 with HTTP; Sat, 5 Nov 2011 14:44:45 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:82765 Archived-At: --20cf307f3630e159f804b103ba39 Content-Type: text/plain; charset=ISO-8859-1 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" 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... > --20cf307f3630e159f804b103ba39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

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 different= ly (?).
> I'm not even sure you _can_ (easily? at all?) obtain the Emacs 23 = behavior using
> Emacs 24. =A0And I'm not sure users will be able to easily underst= and 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. =A0something along the lines of > > (setq display-buffer-alist '(??????))
>
> I wish someone could - or rather, to be more optimistic, I hope someon= e will.
> Unfortunately, I cannot. =A0I'm in the same boat as you, I'm a= fraid.
>
> Believe it or not, one of the main motivations for the changes was sup= posedly to
> make things simpler! =A0It 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 u= sers. =A0(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 contr= ol over
> display details (which window, when, where, etc.). =A0Whether that mix= es well with
> the goal of making things simpler is uncertain.
>
> So instead of a few different user options, we now have the single usi= ne-a-gaz
> `display-buffer-alist'. =A0There seem to be enough knobs and dials= baked into
> `display-buffer-alist' to make its mastery worthy of a doctoral di= ssertation.
>
> And it's only a start, AFAICT. =A0There are also changes to variou= s functions and
> commands, which can affect existing code. =A0You'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. =A0And the behavior seems to be "= ;evolving" (i.e.
> volatile) as (some) bugs get fixed and new ones are introduced. =A0The= re 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. =A0I'm just hoping that things will all be fixed a= nd clearly
> documented before they throw the release itself over the wall to us lu= sers.
>
> Maybe in the end we'll all be far happier for all these changes. = =A0For 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...
>

--20cf307f3630e159f804b103ba39--