Re: The window-pub branch

[grischka]

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

What about the "integrity" of GUD when its attempts to split fail
altogether?  Would rewriting the documentation make GUD happy?

>  > When WINDOW is on another frame, `select-window' does not select
>  > that window for input.
>
> A bug.  How do you make it happen?

Open a second frame, show *scratch*, go to the first frame, show
some file, type
        M-: (select-window (get-buffer-window "*scratch*" t))
type some more chars.

For me, chars go to file (GTK and MS-Windows).

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

I don't use ediff (horrible UI and all).  However if you know how
to improve it you might talk to the ediff people ;)

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

Understandable, since the problem turns out to be difficult, the
assumption is easily made that it must be solved by applications
themselves.

However if anything has only limited awareness of the context then
it's the application.  Except of course when it's the only application
on the entire frame.  In which case there is nothing to solve because
that already works.

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

Sure, I know that.  I was just interested in how far you got.
Maybe you have some snippet that people can try at some point.

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

See also "How it works" on top of ewm.el:
http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-05/msg00026.html

Recipe:
- visit ewm.el
- M-x eval-buffer
- M-: (selected-window)
  #<window 15 on ewm.el>
- F9 ;; compilation window opens
- M-: (selected-window)
  #<window 21 on ewm.el>

So well, it's a bit magic.  UI-wise you're still in the same window with
'ewm.el' but in fact it's different and the old one (#15) is not live-p
anymore.

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

I don't work with approximations.  The less in free software.

> martin