Re: frame-environment

Re: frame-environment

[Michael Ekstrand]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

Chong Yidong <cyd@stupidchicken.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>> What's the story with this function?  It doesn't exist, AFAICS, and
>> its two uses (in `environment' and `read-envvar-name') are commented
>> out.
>>
>> Without this function or something similar, the FRAME argument to
>> `environment' has no effect.  Unless this is for future extensions,
>> I'd suggest to remove it now, before it's too late.
>
> It sounds like an un-implemented or abandoned part of multi-tty.  If so,
> it should certainly be removed.

If this is removed rather than implemented, would that then mean that
there is no way to access the varying environments of frames under
multi-tty?

I have encountered a difficulty with Gnus, multi-tty, and GnuPG that I
have not yet taken time to investigate or do anything about; namely,
when I launch Emacs in my GUI environment, it has access to gpg-agent.
If I SSH in to that machine and connect to Emacs from the shell terminal
session, and try to send a GPG-signed mail, it fails, presumably because
it's trying to use the gpg-agent which is on a locked screen that I'm
not in front of.

It seems that this kind of functionality (sensing the environment of the
current frame), possibly augmented or replaced with the ability to
choose which Emacs process launches an inferior process, is necessary in
order to provide a solution to the problem I have described.

As I said, I have not taken the time to look in to this problem in depth
yet; I've just been working around it.  I just saw the message here and
wanted to make sure that these considerations were brought to light when
deciding what to do with this functionality -- when we have multiple
processes (with multiple environments and differing access to resources)
functioning as one Emacs, situations can arise where the environment of
the process a user is using to initiate a command is important.

I'm cross-posting this to the Gnus list so that the problem is now
brought to light there as well.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: frame-environment

[Stefan Monnier]

> As I said, I have not taken the time to look in to this problem in depth
> yet; I've just been working around it.  I just saw the message here and
> wanted to make sure that these considerations were brought to light when
> deciding what to do with this functionality -- when we have multiple
> processes (with multiple environments and differing access to resources)
> functioning as one Emacs, situations can arise where the environment of
> the process a user is using to initiate a command is important.

Yes, we know about that, it was discussed for a while on this
very list.  It was the kind of motivation that brought the frame's
`environment' parameter.  But this functionality has not been fully
implemented and until this happens, I reverted it to the
previous behavior.  The problem being that while it's sometimes
convenient to use the emacsclient's environment, it can be the wrong
thing to do at other times.

So the emacsserver and emacsclient environments really need to be
"merged" somehow, and there might even be a need to change the way this
merge happens on different occasions.


        Stefan

Re: frame-environment

[Eli Zaretskii]

> From: Michael Ekstrand <michael@elehack.net>
> Date: Sat, 17 Jan 2009 15:37:00 -0600
> Cc: ding@gnus.org
> 
> > It sounds like an un-implemented or abandoned part of multi-tty.  If so,
> > it should certainly be removed.
> 
> If this is removed rather than implemented, would that then mean that
> there is no way to access the varying environments of frames under
> multi-tty?

What are ``the varying environments of frames under multi-tty''?
AFAICS, Emacs doesn't have such a beast.