* Can emacsclient send environment variables even if it doesn't create a frame? @ 2023-03-29 13:45 Yoichi Nakayama 2023-03-29 15:46 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Yoichi Nakayama @ 2023-03-29 13:45 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-03-29 13:45 Can emacsclient send environment variables even if it doesn't create a frame? Yoichi Nakayama @ 2023-03-29 15:46 ` Eli Zaretskii 2023-04-01 13:37 ` Yoichi Nakayama 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2023-03-29 15:46 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-03-29 15:46 ` Eli Zaretskii @ 2023-04-01 13:37 ` Yoichi Nakayama 2023-04-01 13:54 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Yoichi Nakayama @ 2023-04-01 13:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-04-01 13:37 ` Yoichi Nakayama @ 2023-04-01 13:54 ` Eli Zaretskii 2023-04-01 14:28 ` Yoichi Nakayama 2023-04-01 14:54 ` Yoichi Nakayama 0 siblings, 2 replies; 8+ messages in thread From: Eli Zaretskii @ 2023-04-01 13:54 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-04-01 13:54 ` Eli Zaretskii @ 2023-04-01 14:28 ` Yoichi Nakayama 2023-04-01 15:10 ` Eli Zaretskii 2023-04-01 14:54 ` Yoichi Nakayama 1 sibling, 1 reply; 8+ messages in thread From: Yoichi Nakayama @ 2023-04-01 14:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-04-01 14:28 ` Yoichi Nakayama @ 2023-04-01 15:10 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2023-04-01 15:10 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-04-01 13:54 ` Eli Zaretskii 2023-04-01 14:28 ` Yoichi Nakayama @ 2023-04-01 14:54 ` Yoichi Nakayama 2023-04-01 15:40 ` Eli Zaretskii 1 sibling, 1 reply; 8+ messages in thread From: Yoichi Nakayama @ 2023-04-01 14:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Can emacsclient send environment variables even if it doesn't create a frame? 2023-04-01 14:54 ` Yoichi Nakayama @ 2023-04-01 15:40 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2023-04-01 15:40 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: emacs-devel > 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.) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-04-01 15:40 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-29 13:45 Can emacsclient send environment variables even if it doesn't create a frame? Yoichi Nakayama 2023-03-29 15:46 ` Eli Zaretskii 2023-04-01 13:37 ` Yoichi Nakayama 2023-04-01 13:54 ` Eli Zaretskii 2023-04-01 14:28 ` Yoichi Nakayama 2023-04-01 15:10 ` Eli Zaretskii 2023-04-01 14:54 ` Yoichi Nakayama 2023-04-01 15:40 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.