emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Thu, 17 May 2007 18:46:26 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)

>> Actually, the DISPLAY environment should behave that way even
>> without the use of emacsclient (when you use make-frame-on-display).
> Agreed.  But terminal-locality is all that is required (and in my
> opinion appropriate) here.  And it is _not_ a matter of "exporting"
> the start _environment_, but rather of exporting the start _settings_.
> I would argue that an Emacs started with
> DISPLAY=:0.0 emacs -display :1.0
> should export an environment variable DISPLAY=:1.0 to its subprocesses
> unless explicitly overridden.

Agreed, but only to the subprocesses started from frames displayed on
the :1.0 display.  I.e. alway export the DISPLAY on which the selected frame
is displayed.

> This is somewhat complicated by the
> situation given with
> DISPLAY=:0.0 emacs -nw
> In this case, I would still want to export :0.0 to subprocesses, and

In case the frame is not shown on a DISPLAY but on a tty, we should probably
just leave DISPLAY untouched.

> DISPLAY=:0.0 emacs -nw -display :1.0

I have no idea what "-display :1.0" means when passed along with "-nw", so
the behavior probably doesn't matter.

>> Yes, it's probably OK to use frames as an approximation of
>> "terminal" or "display" or "client".

> I disagree.

Actually you don't.  I was saying the above with the assumption that some
kind of inheritence was used so that all frames from the same
terminal/client/display shared the same value.  Which is the implementation
he described.  I don't know why he chose to use frame parameters rather than
terminal-local variables, but if there's a sound reason for it, I don't
think it's a terribly bad choice.

> We don't want to have _any_ such code just break.  It is _not_ code
> that is written sloppily or making unfounded assumptions.  It needs to
> access all environment variables obeying a given pattern and
> manipulate them.  It does this by looping through process-environment
> (more exactly, a copy of it so that the exact implementation of setenv
> can't interfere with the loop).  This is completely straightforward,
> not related to multi-tty-ness at all, and we don't want such usage to
> break.

>From what Karoly says, the above is not fundamentally broken by his code,
except for the need to use the `environment' function.

>> So I'd leave it as a choice that can be determined by the
>> implementation.
> Guffah.  Uh, the implementation will, _of_ _course_, determine _every_
> choice.  That's why we are discussing it.

In my neck of the woods (language theory), when something is "determined by
the implementation", it means that it's specifically left as undetermined by
the spec (e.g. order of evaluation of arguments in C or Scheme).  So it's
not "of course".


        Stefan





reply via email to

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