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

[Karoly Lorentey]

David Kastrup wrote:
> "Károly Lőrentey" <address@hidden> writes:
>> Currently Emacs simply opens the controlling tty of emacsclient
>> directly.
> 
> How would this work over a modem link?

I haven't seen a raw modem link or serial tty in years, but if
/dev/ttyS* is not openable by an independent process of the user, then
emacsclient will fail.  If necessary, we could still make it work by
passing the inherited descriptor to the emacs process using
I_SENDFD/sendmsg/whatever.  I understand that's a messy area of UNIX.

The lazy solution would be to simply add a paragraph to etc/PROBLEMS
suggesting that in these cases the user work inside screen and invoke
emacsclient from there.

Of course, ptys such as those created by SSH, xterm or screen work fine.
 I believe having a working solution for those should be our primary
concern today.

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

Yes.  The use case I tried to optimize for is that of a user invoking
emacsclient as a drop-in replacement for emacs.  Processes started from
the emacsclient session should inherit the environment of the client
process.  If the user extends PATH before invoking emacsclient, this
should (if at all possible) be visible from the emacsclient session.

The process-environment variable still overrides all frame-local
environments, so existing code setting variables by binding
process-environment will still work.

In fact, the only incompatible change in the multi-tty branch that I
know of is that `process-environment' is nil by default.  To enumerate
all environment variables, one needs to call a new function; simply
looking at process-environment does not work.

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

Exactly.

-- 
Karoly