* Re: frame-environment [not found] ` <87ocy596x4.fsf@cyd.mit.edu> @ 2009-01-17 21:37 ` Michael Ekstrand 2009-01-18 1:59 ` frame-environment Stefan Monnier 2009-01-18 4:11 ` frame-environment Eli Zaretskii 0 siblings, 2 replies; 3+ messages in thread From: Michael Ekstrand @ 2009-01-17 21:37 UTC (permalink / raw) To: emacs-devel; +Cc: ding [-- 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 --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: frame-environment 2009-01-17 21:37 ` frame-environment Michael Ekstrand @ 2009-01-18 1:59 ` Stefan Monnier 2009-01-18 4:11 ` frame-environment Eli Zaretskii 1 sibling, 0 replies; 3+ messages in thread From: Stefan Monnier @ 2009-01-18 1:59 UTC (permalink / raw) To: Michael Ekstrand; +Cc: ding, emacs-devel > 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: frame-environment 2009-01-17 21:37 ` frame-environment Michael Ekstrand 2009-01-18 1:59 ` frame-environment Stefan Monnier @ 2009-01-18 4:11 ` Eli Zaretskii 1 sibling, 0 replies; 3+ messages in thread From: Eli Zaretskii @ 2009-01-18 4:11 UTC (permalink / raw) To: Michael Ekstrand; +Cc: ding, emacs-devel > 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-01-18 4:11 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <uprim2cmx.fsf@gnu.org> [not found] ` <87ocy596x4.fsf@cyd.mit.edu> 2009-01-17 21:37 ` frame-environment Michael Ekstrand 2009-01-18 1:59 ` frame-environment Stefan Monnier 2009-01-18 4:11 ` frame-environment Eli Zaretskii
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).