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

[rentey <address@hidden>]

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