emacs-devel
[Top][All Lists]
Advanced

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

Re: Window configurations


From: Juri Linkov
Subject: Re: Window configurations
Date: Wed, 28 Apr 2010 11:27:31 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu)

> The restore step for the overlapping manager would simply ignore
> internal windows.  So we could restore configurations stored by a tiling
> manager in an overlapping manager.

I agree that in a tiling manager internal windows should have coordinates,
and an overlapping manager should ignore windows that don't display buffers
(if a window manager will support displaying windows without buffers
then window definitions should include a new window parameter for them).

> Do you mean left would point to the left neighbor and top to the
> neighbor above?

Yes.

> How would you assign them for a four window configuration like this:
>
>  -----
> |1 |2 |
> |-----|
> |3 |4 |
>  -----
>
> Currently either 1+2 and 3+4 or 1+3 and 2+4 form internal windows.  How
> would you convey that information with relative parameters?

This is easy to do.  Since split window trees are order-dependent,
a list of windows that defines the window configuration in the tiling
manager should be order-dependent too.  Thus

  (window 1
    (buffer . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+2 and 3+4, and

  (window 1
    (buffer . 1))
  (window 3
    (buffer . 3)
    (top-window . 1))
  (window 2
    (buffer . 2)
    (left-window . 1))
  (window 4
    (buffer . 4)
    (top-window . 2)
    (left-window . 3))

will create 1+3 and 2+4.

>> This looks like a new "intangible" window property discussed in the
>> window-group threads.  Have you implemented this in your rewrite of
>> window.c?
>
> It's virtually impossible to do that in a strict sense (unless you go
> for a `post-command-hook').  Note that you can always do a thing like
> (select-window (minibuffer-window)).

This is right that primitives should be able to do this, and
user commands should take restrictions from additional parameters.

> What I've done is to make `other-window' by default not select certain
> window types.  That default can be overridden by window parameters.  And
> I wrote a `window-in-direction' function which does this for the window
> in a given direction (I need this because I never use C-x o).

Ok, I'll wait until you publish a Bzr branch to look at this.

-- 
Juri Linkov
http://www.jurta.org/emacs/




reply via email to

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