[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
moving window handling into lisp
From: |
Miles Bader |
Subject: |
moving window handling into lisp |
Date: |
Mon, 27 Jul 2009 17:32:33 +0900 |
I'm kind of confused by what exactly is going to happen with windows
(multiple competing vaguely-not-satisfying-and-confusing-at-least-
to-my-simple-brain proposals...), but my impression is that it's
desirable to have as much in lisp as possible.
[I apologize if some of what I say below duplicates what's been said
before; I often start zoning out when reading these long threads, and
miss stuff!]
The general approach I've always kind of assumed would be followed by
any extension of window handling in emacs has a very simple basis (at
least it _sounds_ simple :):
** Expose the (existing) window tree to lisp
Basically keep the same window objects we have today, but allow lisp
to get a handle on non-leaf window objects (today, AFAICT, lisp can
only ever see leaf windows).
Together with some low-level accessor/modifier functions, e.g. maybe:
frame-root-window FRAME => ROOT-WIN
window-children WINDOW => (LEFT-CHILD-WIN . RIGHT-CHILD-WIN)
window-parent WINDOW => PARENT-WIN
set-window-children WINDOW LEFT-CHILD-WIN RIGHT-CHILD-WIN
(etc)
A brief look suggests that much of the traditional window handling
code (`window-list', `other-window', `split-window', `delete-window',
`delete-other-windows', etc) could then be moved into lisp; none of
that code looks very complicated or dangerous.
With traditional user-level window handling functions in lisp,
exploring various higher level window frameworks/abstractions seems to
be easier.
Of course the basic assumption is that what we really want is to make
existing lisp windows a bit more malleable, rather than an entirely
new infrastructure.
** Extending window handling
As a separate layer on top of the above, my vague thinking is that the
various fancy behaviors desired for things like ECB could be
implemented as essentially hooks and window-properties etc that affect
the typical user-level window functions (which are now lisp).
For instance (these are simply rough ideas!):
* A window-property which says "treat this window as the window root for
purposes of C-x 1, C-x o, etc". Note that the new low-level primitive
functions (which I listed above) _wouldn't_ be affected, and any lisp
code that wants to see the raw tree, can do so.
* A window property that says (somehow, not sure of the exact form)
"When looking for a window leaf (C-x 0, C-x o, etc), use <parent
window X> instead".
* A buffer-local hook which gets run after setting a window's buffer to
that buffer. (I guess window-configuration-change-hook covers this to
some degree, but it can be annoying to use)
[The first two properties probably would need some means of specifying
different behaviors for different operations -- what you want to
consider a "leaf" might be different depending on whether the user is
moving amongst windows or deleting them.]
Anyway, those are my vague ideas. I hope I'm not simply adding to the
confusion...
-miles
--
Advice, n. The smallest current coin.
- moving window handling into lisp,
Miles Bader <=
- Re: moving window handling into lisp, martin rudalics, 2009/07/27
- Re: moving window handling into lisp, Lennart Borgman, 2009/07/27
- Re: moving window handling into lisp, martin rudalics, 2009/07/27
- Re: moving window handling into lisp, Lennart Borgman, 2009/07/27
- Re: moving window handling into lisp, martin rudalics, 2009/07/27
- Re: moving window handling into lisp, Lennart Borgman, 2009/07/27
- Re: moving window handling into lisp, martin rudalics, 2009/07/27
- Re: moving window handling into lisp, Lennart Borgman, 2009/07/27
- Re: moving window handling into lisp, martin rudalics, 2009/07/27
- Re: moving window handling into lisp, Lennart Borgman, 2009/07/27