emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reordering etc/NEWS


From: David Kastrup
Subject: Re: Reordering etc/NEWS
Date: Sat, 12 May 2007 09:53:33 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux)

Karoly Lorentey <address@hidden> writes:

> David Kastrup wrote:
>> David Kastrup <address@hidden> writes:
>>> address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]