Re: The window-pub branch

[grischka]

martin rudalics wrote:
>  > I found out that hooking ediff to use just 'display-buffer is
>  > actually easy via 'ediff-window-setup-function'.
>
> For some value of easy ;-)
>
>  > Here is some code if you want to test your future version of
>  > 'display-buffer'.  It works quite well with a slightly improved
>  > version of EWM for 'ediff-files'.
>
> What does EWM different from the standard setup of ediff?  I suppose
> you'd use the primary and secondary edit window for the A and B buffer
> and a third one (the compile window maybe) for the H buffer.  Is your
> primary aim to keep things like the sidebar and top windows alive - that
> is to "embed" the ediff windows in the rest of your frame components?

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.

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.

>  > The wrapper calls two functions that you'd
>
> Who is "you"?
>
>  > need to have:
>  >

I apologize, "you" does NOT have to need this.

>  >     my-display-multi-buffers (list-of-buffers-and-labels)
>  >     ;; display some buffers and return list of their windows
>
> I'm currently using the third argument of `display-buffer' as label (I
> call it TAG so far).  For `pop-to-buffer' it's the fourth.

After all it wouldn't be emacs if there were not at least two ways
to do the same thing just not quite.

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

>  > (setq ediff-window-setup-function
> [...]
>  >                (my-display-multi-buffers
>  >                 `((,A . ediff-A)
>  >                   (,B . ediff-B)
>  >                   (,C . ediff-C)
>  >                   (,H . ediff-H)
>
> The great problem I see here is that setting up a window for C might
> depend on _where_ A and B have been displayed before.

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.

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

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

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

> Or do you mean that
> `my-display-multi-buffers' itself should track such window dependencies?

Yes this can be one point to have such interface:  It could consider
dependencies between windows if suitable.  Also it could optimize away
the otherwise very short-lived window configurations.

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.

Other than that my implementation is in fact logically identical to:
  (defun my-display-multi-buffers (alist)
    (mapcar
      (lambda (e) (ewm-display-buffer (car e) (cdr e)))
      alist
      ))
with:
   ewm-display-buffer (buffer &optional label)

--- grischka

> martin