Re: The window-pub branch

[martin rudalics]

> Well, my primary aim was to make some tests in the first place.
> I'v tested with GUD too.  It actually started working after
> I advised 'split-window' to do nothing.

On the GUD frame only, I suppose.  But in this case you could simply
make that frame unsplittable.

> Of course new ideas come to mind soon.  For example support for
> switching the entire layout descriptions in order to have some
> such as an 'ediff-perspective' or 'gud-perspective'. As opposed
> to "embedding" the windows in the existing layout if you want to.

Do I understand correctly that a "perspective" is a layout of a frame
which precludes using or splitting any of the window for another
purpose?  Can't this be made with current means by using unsplittable
frames and dedicated windows?  What else do you need?

>>  >     my-select-window (window)
>>  >     ;; select 'window' and frame where it's on:
>>
>> In what sense is this different from `select-window'?  In some ediff
>> sense (I didn't look into their code)?
>
> No, just different in the sense that it should really work.
> (Also for windows on other frames that is).

Can you give me an example where `select-window' doesn't do what
`my-select-window' would do?

> I was under the impression that it was exactly this problem that you
> wanted to solve.  That is how to show some content such that it's
> combined with some other content in some reasonable way UI-wise.

`display-buffer' is too low level to do that.  Any such context
awareness must be controlled by an application like ediff or GUD via the
specifiers passed to `display-buffer'.

>> Suppose you want
>> to write a `display-buffer-function' for ediff-C: How would you know
>> where A and B are displayed?
>
> I would not want to write such function in the first place.

But you want ediff to use `display-buffer' and you want to intercept
that via your own function.

>> If you can put all in one function (like
>> `ediff-setup-windows-multiframe-merge') things are fairly simple.
>
> For some value of simple ;-)  See ediff-wind.el ...

"fairly" represents one of these values.

>> But with separate display functions things get messy.
>
> But the idea is messy:  That the shared resource screen space could
> be used without proper synchronization.

What should be properly synchronized?

> EWM however neither is trying to optimize nor is it non-deterministic
> as to where show what window.  It has a more basic problem that it
> cannot currently guarantee the live-p-ness of 4 windows as returned
> from distinct calls to ewm-display-buffer.

What exactly is the problem?  Is it that a later call reuses a window
from an earlier call?  Does this happen with window-pub?

martin