emacs-devel
[Top][All Lists]
Advanced

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

Re: The window-pub branch


From: martin rudalics
Subject: Re: The window-pub branch
Date: Mon, 06 Dec 2010 20:41:44 +0100
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

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

With the `split-unsplittable-frame' specifier.

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

An unsplittable frame is a frame that preserves its integrity and a
dedicated window is one that preserves its buffer.  Would rewriting the
documentation make you happy?

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

A bug.  How do you make it happen?

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

Do you want to keep the file text window selected and redirect input to
the control window?

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

I still do.  That is, keeping the customization interface simple and
providing everything that's need by an application is problematic.

>> What should be properly synchronized?
>
> Access from elisp packages to the shared resource screen/frame space.

So far this has been based on a high-level (`display-buffer') interface
and a low-level (`split-window', `delete-window' and
`set-window-buffer') interface.  The former should be used wherever
possible so a user can customize it.  Whether we can fully get rid of
the latter is not yet clear to me.  It's also a question of backward
compatibility and whether we find the people to write it.  Moreover, I
still don't know whether the normal action of C-x b should be affected
by the `display-buffer' options.

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

A frame is never split.  Splitting a window cannot destroy a window
(object).

>  > Does this happen with window-pub?
>
> As well.

As long as you don't give me a recipe I won't believe you.

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

That's a different issue.  Fitting such an object into an existing
window configuration would probably lose most of that object's
properties.  Window configurations are, however, an approximation of
what you want (even if you don't like them).

martin



reply via email to

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