emacs-devel
[Top][All Lists]
Advanced

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

Re: Infrastructural complexity.


From: martin rudalics
Subject: Re: Infrastructural complexity.
Date: Sun, 26 Jul 2009 19:45:02 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

> They are frames.  Frames are modified to have a
> `parent' slot which may be nil or may be a
> frame that itself has a nil `parent'.

Then you have to rewrite the frame management code in addition to the
window management code.  For example, the semantics of both `next-frame'
and `next-window' would change.

>>  decide how they are allowed to
>> tile a frame
>
> Yes.  I have one possibility that seems to cover
> all of the use cases people commonly want, but
> there are other ways to do it, certainly.
>
>> (which would be mostly a copy of the window making,
>> splitting, and deleting code)
>
> Maybe.  There are other possibilities.
> It could also be done with something like
> the layout engines found in some GUI
> toolkits.

These would have to be rewritten and adapted accordingly.

> It's not clear that much or any changes to
> window code would be needed.  Perhaps
> some changes to `display-buffer';  perhaps
> some changes to `buffer-list' that kind
> of thing.  These would be ways for an elisp
> program to limit which buffers are likely to
> be displayed in framelets that are used as control
> panels.

`buffer-list' is not part of the window management code.  But what would
`window-frame' return?  What would the `frame-root-window' of the
`window-frame' of a window be?  Or `selected-frame'?

martin




reply via email to

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