Re: The window-pub branch

[martin rudalics]

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

Note that you can always tweak specifiers in a way such that displaying
buffers fails iff the current way of splitting would fail as well.  Just
that `display-buffer' is less convenient for the application programmer.

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

A clear bug IMHO.  The command loop must switch focus here.

> However if anything has only limited awareness of the context then
> it's the application.

So you _do_ want to embed ediff windows in your frame layout?

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

I'll push my recent changes by the end of the week, hopefully.

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

I think ECB has the same problem.  It's very annoying when you have
overlays with a window property.  These won't apply any more after the
change.

martin