RE: display-buffer-alist simplifications

["Drew Adams" <drew.adams@oracle.com>]

> > I say take the time to get it right.  What's the rush?
> 
> Conversely, as long as the Emacs 23 variables continues to 
> work, we have all the time in the world to introduce the full
> set of new window management features.

Precisely.  So do not include them in Emacs 24.1.  Or include them with a giant
caveat that they are experimental and user code should not depend on them.

IOW, you might want people to play with this, to get some feedback. But you
shouldn't want people to use it seriously and come to expect it to continue as
is.  Play if you want, but do not work with this.

Things that are not fully baked are typically made available in some backdoor
manner (e.g. under a flag/event that users must set, after signing in blood that
they understand that this is not supported).

> The hold-up is fine for now, because meanwhile other bugs are getting
> fixed and the manuals are getting updated.  But the timeline is not
> infinitely elastic---

Why not?  What real deadline does free software development have?  There might
be practical limits such as the lost opportunity of someone not being available
to help after some date, but it's not like you have to deal with contracts and
paying customers.

Let's not exaggerate.  You can do anything you want wrt development schedules.

> the whole point of a feature freeze is that new
> features are supposed to be ready for testing/integration at more or
> less the same time, instead of waiting on one another.

Which is why features that are not ready get pulled from a release.  But the
timing of releases is typically based on concerns and constraints (e.g.
commercial) that Emacs is for the most part not burdened with.

> Another reason I would prefer to reduce the initial set
> of changes to the minimum working set of "base" code

Hey, if that's the case, then either (a) this feature doesn't belong in 24.1 -
save it altogether for 24.2 or (b) 24.1 should wait until this feature is 100%
ready.

And I thought there had already been a decision to do (b).

> is to get that code into the repository sooner rather
> than later.  

In that case your choice is apparently (a) - not include this feature that is
not fully baked in 24.1.