From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Reordering etc/NEWS Date: Sat, 12 May 2007 09:53:33 +0200 Message-ID: <85ejlmh402.fsf@lola.goethe.zz> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1178956426 26968 80.91.229.12 (12 May 2007 07:53:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 May 2007 07:53:46 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: Karoly Lorentey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 12 09:53:42 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 1HmmQ9-0003uL-Rl for ged-emacs-devel@m.gmane.org; Sat, 12 May 2007 09:53:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmmXf-0005OU-5F for ged-emacs-devel@m.gmane.org; Sat, 12 May 2007 04:01:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmmXY-0005Nw-9i for emacs-devel@gnu.org; Sat, 12 May 2007 04:01:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmmXX-0005Nk-FD for emacs-devel@gnu.org; Sat, 12 May 2007 04:01:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmmXX-0005Ne-6f for emacs-devel@gnu.org; Sat, 12 May 2007 04:01:19 -0400 Original-Received: from mail-in-03.arcor-online.net ([151.189.21.43]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HmmQ0-0004Ag-Pd for emacs-devel@gnu.org; Sat, 12 May 2007 03:53:33 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 1A69E2CBAE1; Sat, 12 May 2007 09:53:31 +0200 (CEST) Original-Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id C87522C6EC8; Sat, 12 May 2007 09:53:30 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-053-057.pools.arcor-ip.net [84.61.53.57]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 8F5BB8C46E; Sat, 12 May 2007 09:53:30 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 176121C27956; Sat, 12 May 2007 09:53:33 +0200 (CEST) In-Reply-To: <4644FBFC.6090903@lorentey.hu> (Karoly Lorentey's message of "Sat\, 12 May 2007 01\:27\:56 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:70880 Archived-At: Karoly Lorentey writes: > David Kastrup wrote: >> David Kastrup writes: >>> joakim@verona.se writes: >>>> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have >>>> any value on w32 as far as I can imagine, so I usually just use >>>> Lennart Borgmans w32 emacs package. >>> Why wouldn't it have value? It allows one to keep an existing Emacs >>> session around into which one can connect remotely via ssh+emacsclient >>> in order to do work. At least once emacsclient has been extended with >>> a -nw (--no-window-system) option in order to open a frame on the >>> emacsclient tty. > > Ah, that is good news. If the the Windows port has UN*X-like tty > support, then multi-tty can easily support the use case you describe. > This will still not involve significantly more porting work than simply > fixing the compilation. > >> One additional possibility: with a sufficient level of craziness, you >> might at one point of time link X libraries into Windows executables. >> Then it would be possible to connect into an Emacs session running on >> a Windows system from a system with an X server (either Windows with >> an additional X server, or a posixy system), and have an X frame open >> on that system. > > This would be a very desirable feature, but it needs more work; even the > multi-tty branch doesn't support having multiple kinds of graphical > terminals compiled in at once. 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. 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. Anybody familiar with gnuclient around? How much of the termcap/terminfo stuff is handled at the gnuclient side? Anyway, the approach "pass everything necessary to let the work be done at the application side" _is_ that of X11: pass the contact data for an application agnostic display engine (called an X server) and let the application do the rest. > 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. > Currently people usually run multi-tty Emacs in a detached screen > session that they never connect to. There are simple scripts to > manage this. Screen provides the analogue of a console where you go > to check *Messages* or restart the server when there is trouble. 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. 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum