Re: Pretest begins end-June

[martin rudalics]

>> 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