Can emacsclient send environment variables even if it doesn't create a frame?

Can emacsclient send environment variables even if it doesn't create a frame?

[Yoichi Nakayama]

Currently, emacsclient sends environment variables to the server process only
if it is going to create a frame. So it is impossible to refer to environment
variables when calling EDITOR=emacsclient from other programs.
In contrast, if EDITOR="emacsclient -t" or EDITOR="emacsclient -c" (that is,
emacsclient creates new frames), you can refer emacsclient's environment
variables via server-buffer-clients.

Is it possible to eliminate the following conditional branching by create_frame
in lib-src/emacsclient.c?

  if (create_frame)
    {
      for (char *const *e = environ; *e; e++)
        {
          send_to_emacs (emacs_socket, "-env ");
          quote_argument (emacs_socket, *e);
          send_to_emacs (emacs_socket, " ");
        }
    }

Use case:
Refer GIT_INDEX_FILE to show correct diff even when emacsclient is invoked
by `git commit -a` or `git commit filename` (where GIT_INDEX_FILE points to
a temporary index file), along with the commit message edit buffer.
https://github.com/magit/magit/pull/4888

-- 
Yoichi NAKAYAMA

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Wed, 29 Mar 2023 22:45:09 +0900
> 
> Currently, emacsclient sends environment variables to the server process only
> if it is going to create a frame. So it is impossible to refer to environment
> variables when calling EDITOR=emacsclient from other programs.
> In contrast, if EDITOR="emacsclient -t" or EDITOR="emacsclient -c" (that is,
> emacsclient creates new frames), you can refer emacsclient's environment
> variables via server-buffer-clients.
> 
> Is it possible to eliminate the following conditional branching by create_frame
> in lib-src/emacsclient.c?

That would mean a single frame could "inherit" environment variables
from different shells, which will be at least confusing, if not
contradictory.  For example, what about environment variables like
PATH?

> Use case:
> Refer GIT_INDEX_FILE to show correct diff even when emacsclient is invoked
> by `git commit -a` or `git commit filename` (where GIT_INDEX_FILE points to
> a temporary index file), along with the commit message edit buffer.

Why cannot you call emacsclient in that case with -t or -c option?
AFAIR, Git can use a Git-special variable GIT_EDITOR, so you could
define that to create a new frame without affecting the more general
EDITOR setting.

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Yoichi Nakayama]

On Thu, Mar 30, 2023 at 12:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> > Date: Wed, 29 Mar 2023 22:45:09 +0900
> >
> > Currently, emacsclient sends environment variables to the server process only
> > if it is going to create a frame. So it is impossible to refer to environment
> > variables when calling EDITOR=emacsclient from other programs.
> > In contrast, if EDITOR="emacsclient -t" or EDITOR="emacsclient -c" (that is,
> > emacsclient creates new frames), you can refer emacsclient's environment
> > variables via server-buffer-clients.
> >
> > Is it possible to eliminate the following conditional branching by create_frame
> > in lib-src/emacsclient.c?
>
> That would mean a single frame could "inherit" environment variables
> from different shells, which will be at least confusing, if not
> contradictory.  For example, what about environment variables like
> PATH?

No, it will not update the frame-parameter of the existing frame.
I’ve confirmed
   (frame-parameter nil 'environment) => nil
on the window/buffer created by the modified emacsclient, while
   (process-get (car server-buffer-clients) 'env)
returns environment variables on it.

Also, in the following usage, git will perform exclusive control and
prevent committing to the same repository at the same time, so
multiple clients will not edit the same COMMIT_EDITMSG file.
So the single buffer does not "inherit" environment variables
from different shells.

> > Use case:
> > Refer GIT_INDEX_FILE to show correct diff even when emacsclient is invoked
> > by `git commit -a` or `git commit filename` (where GIT_INDEX_FILE points to
> > a temporary index file), along with the commit message edit buffer.
>
> Why cannot you call emacsclient in that case with -t or -c option?
> AFAIR, Git can use a Git-special variable GIT_EDITOR, so you could
> define that to create a new frame without affecting the more general
> EDITOR setting.

I can use emacsclient with -t or -c option, and I can also use emacsclient
without those option too. If we don't have magit installed, we can edit the
commit message in either case, without any restrictions.

If we have magit installed, in addition to the window for editing the commit
message, it also opens a window for the change diff. I'm trying to fix an
issue with magit that sometimes presents incorrect change diffs.
I found a fix that uses GIT_INDEX_FILE in the client's environment variables
    https://github.com/magit/magit/pull/4888
but it doesn't work if emacsclient doesn't open a new frame. Because
if emacsclient doesn't create a frame, emacsclient's environment variables
aren't passed to the server side and there is no way to use them.

-- 
Yoichi NAKAYAMA

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Sat, 1 Apr 2023 22:37:30 +0900
> Cc: emacs-devel@gnu.org
> 
> On Thu, Mar 30, 2023 at 12:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> > > Date: Wed, 29 Mar 2023 22:45:09 +0900
> > >
> > > Currently, emacsclient sends environment variables to the server process only
> > > if it is going to create a frame. So it is impossible to refer to environment
> > > variables when calling EDITOR=emacsclient from other programs.
> > > In contrast, if EDITOR="emacsclient -t" or EDITOR="emacsclient -c" (that is,
> > > emacsclient creates new frames), you can refer emacsclient's environment
> > > variables via server-buffer-clients.
> > >
> > > Is it possible to eliminate the following conditional branching by create_frame
> > > in lib-src/emacsclient.c?
> >
> > That would mean a single frame could "inherit" environment variables
> > from different shells, which will be at least confusing, if not
> > contradictory.  For example, what about environment variables like
> > PATH?
> 
> No, it will not update the frame-parameter of the existing frame.
> I’ve confirmed
>    (frame-parameter nil 'environment) => nil
> on the window/buffer created by the modified emacsclient, while
>    (process-get (car server-buffer-clients) 'env)
> returns environment variables on it.

That's because we currently refrain from changing the 'environment'
frame parameter -- we tried at some point, and it caused problems we
decided to defer to later.  But it is still an option to do that at
some point, and so I don't want to block that possibility for trhe
benefit of this use case.

> > Why cannot you call emacsclient in that case with -t or -c option?
> > AFAIR, Git can use a Git-special variable GIT_EDITOR, so you could
> > define that to create a new frame without affecting the more general
> > EDITOR setting.
> 
> I can use emacsclient with -t or -c option, and I can also use emacsclient
> without those option too. If we don't have magit installed, we can edit the
> commit message in either case, without any restrictions.
> 
> If we have magit installed, in addition to the window for editing the commit
> message, it also opens a window for the change diff. I'm trying to fix an
> issue with magit that sometimes presents incorrect change diffs.
> I found a fix that uses GIT_INDEX_FILE in the client's environment variables
>     https://github.com/magit/magit/pull/4888
> but it doesn't work if emacsclient doesn't open a new frame. Because
> if emacsclient doesn't create a frame, emacsclient's environment variables
> aren't passed to the server side and there is no way to use them.

I asked why you cannot invoke emacsclient to create a frame, if that
will solve your problem?  Why do you have to insist on using an
existing frame?  What am I missing here?

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Yoichi Nakayama]

On Sat, Apr 1, 2023 at 10:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I asked why you cannot invoke emacsclient to create a frame, if that
> will solve your problem?  Why do you have to insist on using an
> existing frame?  What am I missing here?

I'm using EDITOR='emacsclient -t'. I don't insist on using an existing frame.

I asked this question because I wanted to avoid putting restrictions
on the fix I'm proposing to magit. Since emacsclient can either create
frames or not, I would prefer to have no restrictions in either case.
If emacsclient's limitation remains that there is no way to get the client's
environment variables when it doesn't create a frame, I think I'll have to
accept that my magit fix remains limited.
-- 
Yoichi NAKAYAMA

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Yoichi Nakayama]

On Sat, Apr 1, 2023 at 10:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> > Date: Sat, 1 Apr 2023 22:37:30 +0900
> > Cc: emacs-devel@gnu.org
> >
> > No, it will not update the frame-parameter of the existing frame.
> > I’ve confirmed
> >    (frame-parameter nil 'environment) => nil
> > on the window/buffer created by the modified emacsclient, while
> >    (process-get (car server-buffer-clients) 'env)
> > returns environment variables on it.
>
> That's because we currently refrain from changing the 'environment'
> frame parameter -- we tried at some point, and it caused problems we
> decided to defer to later.  But it is still an option to do that at
> some point, and so I don't want to block that possibility for trhe
> benefit of this use case.

I understand the situation.
However, I would like there to be a way to propagate the client's
environment variables without updating the frame's environment.
Because users of emacsclient don't necessarily want to affect the
entire frame. The server-buffer-clients element has a 1:1
correspondence with clients, so I think it makes sense to always
store client information there. I find it strange that the
server-buffer-clients element doesn't have environment variables
when we don't create a frame.
-- 
Yoichi NAKAYAMA

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Sat, 1 Apr 2023 23:28:12 +0900
> Cc: emacs-devel@gnu.org
> 
> On Sat, Apr 1, 2023 at 10:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > I asked why you cannot invoke emacsclient to create a frame, if that
> > will solve your problem?  Why do you have to insist on using an
> > existing frame?  What am I missing here?
> 
> I'm using EDITOR='emacsclient -t'. I don't insist on using an existing frame.
> 
> I asked this question because I wanted to avoid putting restrictions
> on the fix I'm proposing to magit. Since emacsclient can either create
> frames or not, I would prefer to have no restrictions in either case.
> If emacsclient's limitation remains that there is no way to get the client's
> environment variables when it doesn't create a frame, I think I'll have to
> accept that my magit fix remains limited.

I'd prefer not to pass environment variables unless a new frame is
being created, yes.

Re: Can emacsclient send environment variables even if it doesn't create a frame?

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Sat, 1 Apr 2023 23:54:05 +0900
> Cc: emacs-devel@gnu.org
> 
> > That's because we currently refrain from changing the 'environment'
> > frame parameter -- we tried at some point, and it caused problems we
> > decided to defer to later.  But it is still an option to do that at
> > some point, and so I don't want to block that possibility for trhe
> > benefit of this use case.
> 
> I understand the situation.
> However, I would like there to be a way to propagate the client's
> environment variables without updating the frame's environment.
> Because users of emacsclient don't necessarily want to affect the
> entire frame. The server-buffer-clients element has a 1:1
> correspondence with clients, so I think it makes sense to always
> store client information there. I find it strange that the
> server-buffer-clients element doesn't have environment variables
> when we don't create a frame.

We could perhaps add a new feature, whereby a single environment
variable, or an explicit list of several variables, are passed to the
server and stored in some special variable or a property of the client
process.  But doing this implicitly for the entire environment is
dangerous, unless this is per frame, because if we do this even when a
new frame is not created, the environment variables of the later
client will override those of the former in the 'environment' frame
parameter.  (Your testing indicates that it doesn't, but only because
we currently put the environment into the frame's parameters when we
create a frame.  However, keeping the environment in the process's
property and letting applications access them via the property is not
something I'd like to encourage.)