[Top][All Lists]

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

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

From: David Kastrup
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Thu, 17 May 2007 19:00:36 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

"Károly Lőrentey" <address@hidden> writes:

> David Kastrup wrote:


> You are objecting to having different behaviour in different frames.
> Aren't frame-local Elisp variables equally confusing to you?

Not as long as they are used for frame-specific purposes.  I would
consider it extremely confusing and annoying if suddenly every
variable became frame-locally.  And that is what you do with the

>> Disagree.  It makes shell buffers behave totally unpredictable across
>> terminals (or even worse, frames): the sequence
>> exit RET M-x shell RET
>> usually gets rid of environment variables set within the shell
>> session.  It would not be nice to have to guess what behavior will
>> result.
>> 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.

"Apart from having to replace" means a regression.

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

> But if that's really the case, we can still make
> `process-environment' have a terminal-local binding (with, I assume,
> DEFVAR_KBOARD), and have all existing third-party Elisp code
> continue to work without changes.  Note that this would restrict the
> available designs considerably: all environment variables would have
> to be terminal-local, with no cherry-picking of DISPLAY.

See separate mail for some alternate designs and their respective
drawbacks.  I don't agree with that assessment.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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