[Top][All Lists]

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

Re: Multi-tty design (Re: Reordering etc/NEWS)

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

"Károly Lőrentey" <address@hidden> writes:

> 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.

How would this work over a modem link?

> Environment variables are frame-local and are passed from
> emacsclient to Emacs before the first frame is created.

All of them?  Things like PATH, too?

> 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.

Which is pretty much the situation with X11, too.

> 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).

Ok.  I think we should discuss details once multitty is available via

>>> How to recover when someone accidentally calls server-stop?)
>> Similar to someone "accidentally" calling kill-emacs.
> So if the server stops, Emacs exits.  OK.

If there is no way to contact Emacs anymore, that would seem like a
sensible default once Emacs is idling.

>> 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.

I mean that it appears that most problems can probably be tackled
mostly by documenting the bahavior rather than writing complex code.

> 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.


David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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