|
From: | Thomas Lord |
Subject: | Re: Neat features in Eclipse editor |
Date: | Sun, 23 Mar 2008 14:42:16 -0700 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060808) |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |