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

[David Kastrup]

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

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

Sure.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum