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

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>>> Which is easier if `initial-environment' is called
>>>> `process-environment'...
>>> Well, the opposite is true for existing code that adds stuff to
>>> `process-environment'.  I believe such code is a lot more
>>> widespread.
>> If the way this addition is done is by virtue of "setenv", we can
>> cater for it.
>
> I was thinking of (let ((process-environment (cons FOO
> process-environment)))

Do we actually have code like this around?  It would appear somewhat
strange in pre-multitty since it more or less assumes that
process-environment can contain multiple mentions of environment
variables with only the first taking effect.  At my current computer,
I have multitty checked out.

I suppose I should try setting up some other system that keeps
multiple branches around concurrently.

>> As written in a separate posting: I'd prefer not to have different
>> notions of terminal-local and client-local.
>
> Yes, the argument made sense.  I think we had better try to stick to
> only one such notion.  Since we already have the notion of terminal,
> we should just stick with it.  We will probably want to define that
> we can have two different "pty1" terminals (corresponding to two
> different emacclient sessions).  I think it'd be more difficult to
> do the same with machine:0.0 displays, but if we want and can do
> that, I don't see why I'd oppose it.

We'll need some good strategy for making xterm-mouse-mode and
tmouse-mode be able to show useful behavior.  Never mind backwards
compatibility for those: we need _some_ way where they do what can be
considered "works as expected" without too many contortions.

I am not sure whether it would help or not merging multitty into the
trunk for this.  I don't want people to waste time on hacking things
to work with interfaces of multitty that will certainly change, but at
some point of time we will need to gather extensive experience, and
that means that we should stay open to the possibility of design
changes even when the stuff is in trunk.

-- 
David Kastrup