Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > 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.

Maybe.  How would EWM then split the unsplittable frame?

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

I need a language to express what I want, not what I don't want.
"unsplittable" and "dedicated" are means to suppress rather than
to express.

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

When WINDOW is on another frame, `select-window' does not select
that window for input.

ediff needs input focus on the "control-buffer" window.  Otherwise if
you type 'n' it would not jump to next difference but insert 'n' into
your file text.

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

Question is not "Must it work like that" but "Can it work like that".
Can it?  Last time you were seeing a "great problem".

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

Sure, but for all buffers, not just for ediff-C.  If it's the same
function then it knows of course what windows it has already put
earlier and where.  So also A and B.

>  > But the idea is messy:  That the shared resource screen space could
>  > be used without proper synchronization.
>
> What should be properly synchronized?

Access from elisp packages to the shared resource screen/frame space.

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

No.  It is that any layout change destroys all window objects returned
from earlier calls because the frame is re-split from scratch.

> Does this happen with window-pub?

As well.

Basically what I'd like to have is window-objects that can exist
regardless whether or not they are part of the currently displayed
window tree.

> martin