[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The window-pub branch

From: grischka
Subject: Re: The window-pub branch
Date: Mon, 06 Dec 2010 18:43:59 +0100
User-agent: Thunderbird (Windows/20090812)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]