Ken Raeburn wrote:
> If the code is maintained outside of the Emacs distribution, and doesn't
> drop Emacs 21/22 support immediately, aren't we looking at:
> 
>   (if (fboundp 'environment) (environment) process-environment)
> 
> or something like that?  Or a situation where multiple package
> developers conditionally defines "environment" if it's not already defined?

Sadly, the situation was a little more complex than that.

> The more I read about it, the more it seems that the multi-tty code is
> changing the concept of an Emacs editing session, so I wouldn't expect
> the changes to be confined to tty handling.

A good example of this is that the multi-tty branch supports
simultaneous X and tty frames.  This feature is fundamentally
incompatible with any Lisp package that initializes window-system
dependent variables at load-time.  There are quite a few of those.
However, single-terminal users don't need to adapt code, so we can say
we are backwards compatible.

> I haven't decided yet what I think the multi-tty code should do
> regarding environments, but for years I was using gnudoit to invoke
> make-frame-on-display with $DISPLAY and a handful of frame settings
> derived from environment variables, combined with hacks to update the
> environment when switching frames, so I definitely think some
> environment variables should be easy to switch based on where you're
> currently coming from.  (I'm intentionally avoiding "client" and "frame"
> here.)  And if it's not all environment variables, then it should be an
> easily-changed list.

Excellent, so I'm not the only one with crazy concepts of local
environment variables. :-)

> Now, though, I use the Mac version a lot, so remote access went away...
> until now; multi-tty seems like a good step in the right direction.  I'm
> still hoping for X11 as well as Carbon in the same process though. :-) 

There were much too many toolkit #ifdefs for my taste.  But it has been
years since I looked at this, maybe it'd be feasible to do this now.

-- 
Karoly