From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Neat features in Eclipse editor Date: Sun, 23 Mar 2008 14:42:16 -0700 Message-ID: <47E6CEB8.9050605@emf.net> References: <873aqia0eh.fsf@stupidchicken.com> <873aqiw4xm.fsf@jurta.org> <47E636CB.1050607@gmx.at> <47E6B1F0.7080909@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040905070301080405060204" X-Trace: ger.gmane.org 1206306203 4869 80.91.229.12 (23 Mar 2008 21:03:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2008 21:03:23 +0000 (UTC) Cc: emacs-devel To: "John S. Yates, Jr." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 23 22:03:53 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JdXM8-0003aK-SW for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 22:03:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdXLX-0006P7-PW for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 17:03:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdXLT-0006Mj-GG for emacs-devel@gnu.org; Sun, 23 Mar 2008 17:03:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdXLQ-0006Jd-IW for emacs-devel@gnu.org; Sun, 23 Mar 2008 17:03:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdXLQ-0006JW-Ew for emacs-devel@gnu.org; Sun, 23 Mar 2008 17:03:08 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JdXLP-0006dI-NA for emacs-devel@gnu.org; Sun, 23 Mar 2008 17:03:08 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 26219622; Sun, 23 Mar 2008 14:02:46 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:93265 Archived-At: This is a multi-part message in MIME format. --------------040905070301080405060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > > > > --------------040905070301080405060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------040905070301080405060204--