frame-environment

frame-environment

[Eli Zaretskii]

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.

Re: frame-environment

[Eli Zaretskii]

> Date: Sat, 17 Jan 2009 17:08:54 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> 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.

In addition, the first part of this bit of `environment's doc string
is simply a lie:

    The list is constructed by concatenating the elements of
    `process-environment' and the 'environment parameter of the
    selected frame, and removing duplicated and empty values.

Unless someone intends to implement what it says before the release, I
suggest to remove the first part of this sentence from the doc string.

Re: frame-environment

[Juanma Barranquero]

On Sat, Jan 17, 2009 at 16:25, Eli Zaretskii <eliz@gnu.org> wrote:

> In addition, the first part of this bit of `environment's doc string
> is simply a lie:

The docstring for getenv-internal also seems to have problems:

   If optional parameter ENV is a list, then search this list instead of
  `process-environment', and return t when encountering a negative entry.

What does it mean "when encountering a negative entry"?

Then:

  If it is a frame, then this function will ignore `process-environment' and
  will simply look up the variable in that frame's environment.

But the function does:

  if (CONSP (env))
    ;;; [....]
    ;;; this is the non-frame case, then:
    ;;;
  else if (getenv_internal (SDATA (variable), SBYTES (variable),
			    &value, &valuelen, env))
    return make_string (value, valuelen);

and getenv_internal's first lines are:

  /* Try to find VAR in Vprocess_environment first.  */
  if (getenv_internal_1 (var, varlen, value, valuelen,
			 Vprocess_environment))
    return *value ? 1 : 0;

so it seems like the variable is looked up in the process environment
even if ENV is a frame.

Moreover, getenv_internal only looks for one specific variable in the
"frame envionment", namely DISPLAY:

  if (strcmp (var, "DISPLAY") == 0)
    {
       ;;; look for frame parameter 'display
    }

  return 0;


    Juanma

Re: frame-environment

[Chong Yidong]

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.

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]

> 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.

It doesn't exist.

> 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.

I'm not sure how to remove it since it doesn't exist, but yes, it should
be removed.  As for the `environment' frame-parameter, we can drop it if
we want, or at least rename it to server-environment (tho a more
precise name would be confusingly server-client-environment).


        Stefan

Re: frame-environment

[Stefan Monnier]

>> In addition, the first part of this bit of `environment's doc string
>> is simply a lie:

> The docstring for getenv-internal also seems to have problems:

>    If optional parameter ENV is a list, then search this list instead of
>   `process-environment', and return t when encountering a negative entry.

> What does it mean "when encountering a negative entry"?

An entry of the form "VAR" instead of "VAR=VAL".  Such an entry means
"remove VAR from the environment", IIRC.

>   If it is a frame, then this function will ignore `process-environment' and
>   will simply look up the variable in that frame's environment.

This is out-of-date and should be removed.

> Moreover, getenv_internal only looks for one specific variable in the
> "frame envionment", namely DISPLAY:

This is not the "frame environment" (which is the `environment'
frame-parameter).


        Stefan

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

[Juanma Barranquero]

On Sun, Jan 18, 2009 at 02:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> An entry of the form "VAR" instead of "VAR=VAL".  Such an entry means
> "remove VAR from the environment", IIRC.

Is that standard terminology? I've never heard it.

> This is not the "frame environment" (which is the `environment'
> frame-parameter).

Sorry, I should've said "it only uses the frame parameter to look for
one variable, DISPLAY".

The docstring needs a patch like the attached one, which more
accurately reflects what Fgetenv_internal does. I say "like" because
that docstring still doesn't explain the special case where

  if ((variable is "DISPLAY")
      && (ENV is not a list)
      && ("DISPLAY" not found in `process-environment')
      {
          if (ENV is a frame)
              return `display' parameter of ENV;
          else if (ENV is nil)
              return `display' parameter of selected frame;
          else
              error;
      }

    Juanma


Index: src/callproc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/callproc.c,v
retrieving revision 1.243
diff -u -2 -r1.243 callproc.c
--- src/callproc.c	8 Jan 2009 03:15:26 -0000	1.243
+++ src/callproc.c	18 Jan 2009 02:30:41 -0000
@@ -1391,13 +1391,9 @@
 the environment.  Otherwise, value is a string.

-This function searches `process-environment' for VARIABLE.  If it is
-not found there, then it continues the search in the environment list
-of the selected frame.
+This function searches `process-environment' for VARIABLE.

 If optional parameter ENV is a list, then search this list instead of
-`process-environment', and return t when encountering a negative entry.
+`process-environment', and return t when encountering a negative entry
+\(an entry for a variable with no value).  */)
-
-If it is a frame, then this function will ignore `process-environment' and
-will simply look up the variable in that frame's environment.  */)
      (variable, env)
      Lisp_Object variable, env;

Re: frame-environment

[Stefan Monnier]

>> An entry of the form "VAR" instead of "VAR=VAL".  Such an entry means
>> "remove VAR from the environment", IIRC.
> Is that standard terminology? I've never heard it.

I don't think it's a standard feature (it's specific to Emacs's
process-environment, AFAIK), and even less standard terminology.

> The docstring needs a patch like the attached one, which more
> accurately reflects what Fgetenv_internal does. I say "like" because
> that docstring still doesn't explain the special case where

Feel free to apply it.


        Stefan

Re: frame-environment

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 17 Jan 2009 20:48:24 -0500
> 
> > 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.
> 
> I'm not sure how to remove it since it doesn't exist

I meant to remove the FRAME argument to the `environment' function.
Sorry for being unclear.

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.

Re: frame-environment

[Michael Ekstrand]

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

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

The concept I am trying to get at (and has been discussed, according to
Stefan's message yesterday) is that the different processes involved in
Emacs have different environments.  I may be associating them with the
wrong entity, but if I have several GUI frames on my desktop, and then
another frame displayed via emacsclient -t.  emacsclient may have a
different environment than the master Emacs process.  That different
environment may be important (e.g. for running GnuPG properly).  Thus,
in the long term, in order to Do The Right Thing in a multi-tty
environment, it is necessary to be able to know about multiple
environments and be able to select the correct one; the description of
the code in question lead me to believe that the approach to this was
associating environments with frames.

- 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]

>> > 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.
>> 
>> I'm not sure how to remove it since it doesn't exist

> I meant to remove the FRAME argument to the `environment' function.
> Sorry for being unclear.

Actually, you can remove that function altogether.


        Stefan

Re: frame-environment

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 18 Jan 2009 15:36:15 -0500
> 
> >> > 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.
> >> 
> >> I'm not sure how to remove it since it doesn't exist
> 
> > I meant to remove the FRAME argument to the `environment' function.
> > Sorry for being unclear.
> 
> Actually, you can remove that function altogether.

Are you sure?  It seems mildly useful, since it removes duplicate and
unset variables.

Re: frame-environment

[Stefan Monnier]

>> Actually, you can remove that function altogether.
> Are you sure?  It seems mildly useful, since it removes duplicate and
> unset variables.

It's never been used.



        Stefan

Re: frame-environment

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 19 Jan 2009 23:53:10 -0500
> 
> >> Actually, you can remove that function altogether.
> > Are you sure?  It seems mildly useful, since it removes duplicate and
> > unset variables.
> 
> It's never been used.

Removed.