[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Infrastructural complexity.
From: |
Thomas Lord |
Subject: |
Re: Infrastructural complexity. |
Date: |
Sun, 26 Jul 2009 11:34:52 -0700 |
On Sun, 2009-07-26 at 19:45 +0200, martin rudalics wrote:
> > 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.
It might be desirable - though probably not
necessary - to *tweak* `next-frame' in a
small way.
Why would you change `next-window'? Is it
that you want C-x o to jump from edit area
windows to control panels and back again?
Maybe `next-frame', maybe a new command.
Leaving `next-window' alone means that the
edit area can act like "Emacs classic" with
the control panels serving as a new way
to invoke commands that effect the
window and buffer currently selected in
the edit area.
> >> 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 shouldn't be very much code.
> > 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?
The containing frame(let), just as it does
now. Control panel modes - for use in
buffers displayed in control panels - can
use a new function in some cases:
(defun window-parent-frame (w)
(if (frame-parent (window-frame w))
(frame-parent (window-frame w))
(window-frame w)))
> What would the `frame-root-window' of the
> `window-frame' of a window be? Or `selected-frame'?
The root window of the frame, just as it is
now. Control panel modes could use, in some
cases, (frame-root-window (window-parent-frame))
-t
> martin
- Re: AW: AW: Infrastructural complexity., (continued)
- Re: AW: AW: Infrastructural complexity., Thomas Lord, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Thomas Lord, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/26
- Re: Infrastructural complexity., martin rudalics, 2009/07/26
- Re: Infrastructural complexity., Thomas Lord, 2009/07/26
- Re: Infrastructural complexity., martin rudalics, 2009/07/26
- Re: Infrastructural complexity.,
Thomas Lord <=
- Re: Infrastructural complexity., martin rudalics, 2009/07/27
- Re: Infrastructural complexity., Thomas Lord, 2009/07/27
- Re: Infrastructural complexity., martin rudalics, 2009/07/27
- RE: Infrastructural complexity., Drew Adams, 2009/07/27
- Re: Infrastructural complexity., martin rudalics, 2009/07/27
- RE: Infrastructural complexity., Drew Adams, 2009/07/27
- Re: Infrastructural complexity., martin rudalics, 2009/07/28
- RE: Infrastructural complexity., Drew Adams, 2009/07/28
- Re: Infrastructural complexity., martin rudalics, 2009/07/29
- Re: Infrastructural complexity., Thomas Lord, 2009/07/27