[Top][All Lists]

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

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

From: rentey <address@hidden>
Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
Date: Thu, 17 May 2007 16:35:06 +0200
User-agent: Thunderbird (Windows/20070326)

Stefan Monnier wrote:
>>      - At least some environment variables _must_ behave locally; if not
>>        client-locally, then at least terminal-locally.  DISPLAY is perhaps
>>        the most obvious example.  X clients such as xdvi started from Emacs
>>        must appear on the display the user currently works on.
> Actually, the DISPLAY environment should behave that way even without the
> use of emacsclient (when you use make-frame-on-display).

Hm, this is a good point.

>>        This is an important feature for multi-tty users and I would like
>>        to keep it supported.  Similar variables include SSH_AUTH_SOCK,
>>        GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and basically anything
>>        that may be different from login session to login session.
> I don't think the vars you list are particularly important.  Which version
> of those vars to use (the one from the emacsclient process or from the main
> Emacs process) may depend from case to case.  So either choice is
> probably OK.

Well, I do agree that having a local DISPLAY is the essential feature here.

> I tend to think of emacsclient as "connect to the main Emacs process", so
> I tend to expect it to work in the environment of the main Emacs process.
> You seem to think of it as "pretend you're a normal Emacs process, just
> quick-started", so you expect a slightly different behavior.

The new emacsclient behaviour does make it easy to forget that you are
connecting to a separate Emacs process that runs in the background,
particularly when the main Emacs is not visible.  But I feel both
viewpoints can be catered for; "emacsclient --current-frame" reverts to
Emacs 22 behaviour, and should not touch the environment.

>>      - Furthermore, to me it seems more consistent to have all
>>        environment variables be local than just a select few of them.
> I don't find it important, but it doesn't seem to be bad either.  So I'd
> leave it as a choice that can be determined by the implementation.



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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