John S. Yates, Jr. wrote: 
Thomas Lord writes:

  
Even better, add a few functions to emacs and turn it into an
X11 window manager, extensible in self-documenting lisp.
Consider the root window as a frame.
    

Has already been done:

  http://www.emacswiki.org/cgi-bin/wiki/XWindowEmacsManager

Thanks for the pointer.  That looks like a nice attempt.   It's interesting
that the author "confesses" uncertainty about how to handle windows
from random clients because I think that's one of the areas it's easy to
wrong.   I'm skeptical of the idea of trying to equivocate a managed
client with something like a frame.   But yes, that's the general direction.


The problem is that a few functions alone do not a polished window manager
make.

Totally true.   I have no argument with that.


 Do you honestly believe that the emacs community would find the
expertise, the focus and the bandwidth to match any of the projects that I
cited?

No, I don't *believe* it might.  I honestly *wonder* if it might.  It seems
plausible to me.




 I am sure that it would do a competent job organizing and laying out
emacs windows.  I have much less confidence that the idiosyncrasies of windows
displayed by the full panoply of non-emacs applications would receive
comparable attention.

I agree that that's the hard part.   I am thinking there are probably several 10s
of pages of very tediously detailed code to get right.



There is also an important argument against having emacs at the bottom of the
stack.  So long as emacs remains single threaded both window and input event
management would likely freeze each time emacs became busy.

Yes.   That's serious and I'm encouraged that you brought that up.

I can think of two architectural approaches that might help with that
problem.  

One approach is to make the "Emacs-as-WM" dedicated to mostly just
that.   Yes, it might leverage its text-editor functionality in lots of ways,
but that isn't the Emacs process that user's use for anything *but*
being a WM.   It's still single threaded -- but it doesn't ever get "busy".

Another approach is that, sure, the WM-Emacs is your main Emacs
and yes, it still is annoyingly single threaded with pauses etc.... *but*...
window management is driven indirectly.   There is some external
process that Emacs talks to.   That external process is some simple kind
of state machine that knows how to move windows around, paint
frames in parent windows, etc..... but that is basically "table driven".
The parent Emacs asyncronously changes the rules that that other process
uses but, meanwhile, that other process is handling X window mgt.
without pausing.

-t





/john