Re: Pretest begins end-June

[martin rudalics <rudalics@gmx.at>]

 >> The final step will break a number of functions using buffer
 >> display routines, notably in org, gud, calculator and calendar code,
 >> which I cannot fix alone because I often don't understand the authors'
 >> intentions.  It very likely will also break external packages which I
 >> don't know like Drew's Icicles.  So I'll need some help there.
 >
 > Can you explain the kind of breakage and the reason why the change has
 > to introduce these incompatibilities?

The breakage occurs because `display-buffer' now expects that _all_
directives wrt where and how to display the buffer must be passed via a
list in the second argument (which was formerly called `other-window'
and is now called `specifiers') and the user customization of the
behavior of `display-buffer' occurs independently in a new option called
`display-buffer-alist'.

The reason for this change was one of your earlier postings

 > Rather than let-binding some Lisp-manipulated "config" var, I was
 > thinking of passing special parameters to display-buffer ...

and Juri Linkov's subsequent proposal

 > Why not use the existing argument `other-window'
 > of `pop-to-buffer' and `display-buffer'?

Hence, if an application now wants to pop up a buffer in another frame
it must do something like

(pop-to-buffer buffer-or-name 'other-frame)

instead of

(let ((pop-up-frames t))
   (pop-to-buffer buffer))

The breakage will usually cause a call like the later to simply follow
the user customizations for how to display "buffer".  I changed most of
the trivial calls already but some are rather special.

martin