From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?K=E1roly_Lo=22rentey?= Newsgroups: gmane.emacs.devel Subject: Multi-tty design (Re: Reordering etc/NEWS) Date: Sat, 12 May 2007 14:09:49 +0200 Message-ID: <4645AE8D.8080004@lorentey.hu> References: <2wmz0iriyj.fsf@fencepost.gnu.org> <87fy65k6eh.fsf@red-bean.com> <853b25lk43.fsf@lola.goethe.zz> <87sla5iqhs.fsf@red-bean.com> <85sla5k4py.fsf@lola.goethe.zz> <4642C8C9.5050804@gnu.org> <86tzul15ky.fsf@lola.quinscape.zz> <4642E388.9010503@gnu.org> <86odktypii.fsf@lola.quinscape.zz> <86k5vhyoo8.fsf@lola.quinscape.zz> <4644FBFC.6090903@lorentey.hu> <85ejlmh402.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1178971804 28326 80.91.229.12 (12 May 2007 12:10:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 May 2007 12:10:04 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 12 14:10:02 2007 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 1HmqQD-00044M-Vo for ged-emacs-devel@m.gmane.org; Sat, 12 May 2007 14:10:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmqXk-0006Gh-FQ for ged-emacs-devel@m.gmane.org; Sat, 12 May 2007 08:17:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmqXg-0006GN-A9 for emacs-devel@gnu.org; Sat, 12 May 2007 08:17:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmqXd-0006GB-T7 for emacs-devel@gnu.org; Sat, 12 May 2007 08:17:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmqXd-0006G8-NB for emacs-devel@gnu.org; Sat, 12 May 2007 08:17:41 -0400 Original-Received: from ninsei.hu ([212.92.23.158]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HmqQ5-0007mZ-2w; Sat, 12 May 2007 08:09:53 -0400 Original-Received: from [192.168.1.12] (catv5403A040.pool.t-online.hu [84.3.160.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id B66F178FD; Sat, 12 May 2007 14:09:51 +0200 (CEST) User-Agent: Thunderbird 1.5.0.10 (X11/20070403) In-Reply-To: <85ejlmh402.fsf@lola.goethe.zz> X-Enigmail-Version: 0.94.2.0 X-detected-kernel: Linux 2.6 (newer, 3) 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:70888 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Kastrup wrote: > Well, the _proper_ multiplatform way of things would be to extend > emacsclient with a display engine. Then only system-independent data > would need to cross between emacs and emacsclient, and it would not be > a problem to open a Carbon emacsclient connecting to a Windows > emacsserver. Yeah, that would be great. However, implementing a "properly" device-independent client-server model was never the purpose of the multi-tty branch. > Complete independency is probably illusionary. gnuclient opens its > own frame in a tty (I don't think emacsclient has this sort of > operation). I would guess that it passes the terminal geometry and > TERM variables through the socket and basically lets Emacs talk to the > tty through its socket, shutting down when Emacs tells it. Currently Emacs simply opens the controlling tty of emacsclient directly. Environment variables are frame-local and are passed from emacsclient to Emacs before the first frame is created. Signals such as SIGWINCH, SIGTSTP, SIGTTOU and SIGCONT are handled and forwarded to Emacs in a sensible way. Emacs does most of the tty-related work, emacsclient simply stands out of the way. Previously, there was a stage when emacsclient created a screen-like proxy pseudo-tty and had Emacs open that. The added complexity really did not win us anything important (apart from having "su otheruser emacsclient" work). Using the emacsclient socket to transmit tty data is an intriguing idea, but it would mean duplicating the hairy tcsetattr/ioctl/curses/whatever magic of Emacs inside emacsclient without a clear and immediate benefit. The current way of having Emacs handle these parts is the least intrusive solution, so that's what I had to implement. Once basic multi-tty functionality is on the trunk, we can extend it in any exotic way we want. >> I intentionally left implementing frameless Emacs sessions after the >> merge, to let us discuss this proposed feature extensively on >> emacs-devel. I think we need to make non-trivial design decisions. >> (Where do messages go when there are no frames? > > In the *Message* buffer, obviously. >> How to recover when someone accidentally calls server-stop?) > > Similar to someone "accidentally" calling kill-emacs. So if the server stops, Emacs exits. OK. > When there is trouble with a server, one sends it a signal manually. > I don't see that there are too many things around which require code > rather than decisions. I can't understand this last sentence. My point is that allowing frameless Emacs instances is not hard to implement, but it is a non-essential feature and I judged it is better deferred after the merge. (Technically, a frameless Emacs would still have one frame with a dummy display device. Emacs relies on always having a current frame too strongly.) > It is not our task to prevent people shooting > themselves in the foot if they really want to. We should not make it > trivially easy to trigger an accident by default, but that's about it. That's fine. - -- Karoly -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRa6N6eoyqA+yej8RAp8bAJ4gtSD4Al+5OmObkoYbogc4AYrHSACfY20x aXqE2VWRE/E28+8QqXQOoiE= =6wrs -----END PGP SIGNATURE-----