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

[Ken Raeburn]

On May 17, 2007, at 13:00, David Kastrup wrote:
> "Károly Lőrentey" <address@hidden> writes:
> > David Kastrup wrote:
>
>
> > > AUCTeX, for example, contains code like the following:
> >
> > AFAICT, apart from having to replace the process-environment
> > reference with '(environment)', the quoted code will work just fine
> > on the multi-tty branch.

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?

If we already had a major release or two with an "environment"  
function, and flag process-environment references as obsolete,  
telling people to just use "environment" might be more reasonable.

> "Apart from having to replace" means a regression.

It means a documented incompatible change, which is not necessarily  
the same thing.

> > > We don't want to have _any_ such code just break.
> >
> > Really?  No incompatible change is ever allowed?  Not even in a new
> > major version?  I would like to have a second opinion on that from
> > other developers.
>
> In my opinion, a new feature in connection with ttys should, if at
> all, break only code that is also connected with ttys.  That is
> expectable breakage.  The current implementation breaks pretty much
> everything that works with environments.

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.

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.

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. :-)  (Yes, I could use X11 on the Mac display, but  
the Carbon UI feels better integrated into the system.)

Ken