[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Raeburn
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Thu, 17 May 2007 16:02:52 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]