Re: Annoying window/frame-configuration registers

[martin rudalics]

> Cool, I can start to use the branch then. Would simply using the branch
> in daily work be enough of a test?

For some features like window splitting, resizing, and deleting the
answer is yes.  Others features like side windows or atomic windows are
completely new so it would make sense to check the Elisp manual sections
on these first.

> I still have the original use case that we did the "window group" patch
> for. Does your branch cover the case of having multiple window groups
> and pinnable windows?

It's mostly in what I call "side windows" now.  I'm currently working on
a more expanded version of this but what there is in the branch should
be enough to start working.  In particular, it should suffice to
implement ECB without any advices and similar tricks.

>> PS: Some changes in the `display-buffer' department are guaranteed to
>> break existing code.
>
> Are clients supposed to adopt or the other way around?

Adopt.  There are two major changes:

(1) All `display-buffer' related options have been concentrated in one
    single option called `display-buffer-alist'.  Obviously, this
    affects users as well but there is a function to convert a user's
    settings to values for the new option.

(2) The semantics of the second and third argument of `display-buffer'
    have completely changed their meaning.  This will affect mostly
    components like calendar, gdb, gnus, org-mode and calculator.  I
    have changed the code in most other clients already.

The other changes I made should not be noticeable in daily work.  But
since my workflow is quite different from that of other people there's a
chance that I have broken some standard behavior.  That's what I would
need testers for.

martin