RE: Marking old window variables obsolete

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

> The new display-buffer machinery still supports the following 
> variables:
> 
> special-display-buffer-names
> special-display-regexps
> special-display-frame-alist
> special-display-function
> same-window-buffer-names
> same-window-regexps
> display-buffer-reuse-frames
> 
> I think we can mark these as obsolete for 24.2.  Any objections?
> 
> There's also pop-up-frames and pop-up-windows, but I think we 
> can wait a few releases before marking those as obsolete.

FWIW and for the record, I disagree with _all_ of that proposal.  Please do not
do this.  There should be _no_ hurry to do anything of the sort.  Why can't you
wait a few releases - or more - for all of the above?

In fact, I would like to see these variables continued anyway, as (to me, at
least), a much simpler, alternative way to customize buffer display.  If the
variables have fancy equivalents in the new machinery, fine.  Let users choose:
fancy or simple, super-general or (presumably) more limited.

I do not claim _any_ expertise in this area - far from it.  And that's one
reason I ask that the simple approach be kept (as well as the more complex).

You might be able to do more and better with the new system - or as you say
"machinery" (usine a gaz?), but it does not seem (to me) to be so
straightforward (simple) to use.

It is still not clear to me how to - easily - replace the above user options,
and I use them heavily.  The doc regarding the new machinery, if not the
machinery itself (can't speak to that), is impenetrable, for me.

I'm sorry to say that, and I tried to raise the doc problem early, but I still
do not see a clear explanation.  Perhaps that is just a reflection of how
complicated the machinery is - I can't judge, for lack of understanding.

Just one, dumb user - who happens to actually _use_ the simple variables you are
in a hurry to toss overboard.  

(Out of curiosity, I wonder how much those who came up with the new machinery
ever actually used those variables.  I don't argue that the machinery is bad or
is implemented badly - on the contrary, I am convinced that Martin and others
did a great job.  But I wonder about its use value and ease of use, at least for
some users.)