[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can emacsclient send environment variables even if it doesn't create
From: |
Eli Zaretskii |
Subject: |
Re: Can emacsclient send environment variables even if it doesn't create a frame? |
Date: |
Sat, 01 Apr 2023 16:54:50 +0300 |
> 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?