GNU bug report logs - #47806
28.0.50; `make-frame` frame should probably clone the `environment` parameter into the new frame

Previous Next

Package: emacs;

Reported by: Thibault Polge <thibault <at> thb.lt>

Date: Thu, 15 Apr 2021 18:30:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47806 in the body.
You can then email your comments to 47806 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Thu, 15 Apr 2021 18:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thibault Polge <thibault <at> thb.lt>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 15 Apr 2021 18:30:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thibault Polge <thibault <at> thb.lt>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; `make-frame` frame should probably clone the `environment`
 parameter into the new frame
Date: Thu, 15 Apr 2021 20:28:59 +0200
Hello,

Frames created by `emacsclient` get a copy of the caller's environment
variables in the `environment` frame property.  But frames created from
other frames (with C-x 5 2, `make-frame`, `make-frame-command`, and so
on) don't get a copy of those variables (they don't have an
`environment` frame parameter at all). I believe they should.

My use case is talking to the WM, and without this parameter I believe
it's impossible to distinguish between, eg, frames managed by different
X servers on the same daemon.

FWIW, I'm running Emacs from revision
738266240dc1a19911770bf676330aa72352da79 (from April 6th) built with the
Lucid toolkit.

Best regards,
Thibault




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Thu, 15 Apr 2021 19:10:02 GMT) Full text and rfc822 format available.

Message #8 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 47806 <at> debbugs.gnu.org
Subject: Re: bug#47806: 28.0.50;
 `make-frame` frame should probably clone the `environment` parameter
 into the new frame
Date: Thu, 15 Apr 2021 22:08:38 +0300
> From: Thibault Polge <thibault <at> thb.lt>
> Date: Thu, 15 Apr 2021 20:28:59 +0200
> 
> Frames created by `emacsclient` get a copy of the caller's environment
> variables in the `environment` frame property.  But frames created from
> other frames (with C-x 5 2, `make-frame`, `make-frame-command`, and so
> on) don't get a copy of those variables (they don't have an
> `environment` frame parameter at all). I believe they should.

How do we know whether a particular frame should or shouldn't have the
'environment' frame parameter?  When the frame is created by the
server on behalf of a client, we know.  But for a random
frame-creation function, how do we know?

> My use case is talking to the WM, and without this parameter I believe
> it's impossible to distinguish between, eg, frames managed by different
> X servers on the same daemon.

Doesn't the 'display' parameter fit the bill?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Thu, 15 Apr 2021 19:48:02 GMT) Full text and rfc822 format available.

Message #11 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Thibault Polge <thibault <at> thb.lt>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47806 <at> debbugs.gnu.org
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Thu, 15 Apr 2021 21:47:01 +0200
> Doesn't the 'display' parameter fit the bill?

Not on Wayland, I'm afraid.  I believe all the XWayland instances will
have the same value for `display`, which may be a non-usable value.  I'm
also not sure that we can go from `display` to the Wayland server.  (As
an example, in my case, what I actually need is `SWAYSOCK`).

> How do we know whether a particular frame should or shouldn't have the
> 'environment' frame parameter?  When the frame is created by the
> server on behalf of a client, we know.  But for a random
> frame-creation function, how do we know?

That's a tricky question.  In my understanding, it makes sense in an
ancestor/child relationship: if the ancestor of FRAME has some distinct
set of environment variables, we copy them to the new frame.  I'm not
too clear on the various execution contexts of Emacs Lisp, but couldn't
something similar to:

(when (called-interactively-p) ; I assume this implies there's a frame
                               ; this is being called "from".
  (set-frame-property TARGET 'environment
                      (frame-property SOURCE 'environment')))

To clarify all my assumptions, I understand that the `environment`
property exists because frames of the same daemon or server can appear
in very different environments, like multiple X or Wayland servers,
terminals, remote sessions, and so on. If my understanding is correct,
it makes sense that further frames share these values, even when not
created directly from `emacsclient`.

Best regards,
Thibault




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Thu, 15 Apr 2021 19:55:02 GMT) Full text and rfc822 format available.

Message #14 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 47806 <at> debbugs.gnu.org
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Thu, 15 Apr 2021 22:54:27 +0300
> From: Thibault Polge <thibault <at> thb.lt>
> Cc: 47806 <at> debbugs.gnu.org
> Date: Thu, 15 Apr 2021 21:47:01 +0200
> 
> > Doesn't the 'display' parameter fit the bill?
> 
> Not on Wayland, I'm afraid.  I believe all the XWayland instances will
> have the same value for `display`, which may be a non-usable value.  I'm
> also not sure that we can go from `display` to the Wayland server.  (As
> an example, in my case, what I actually need is `SWAYSOCK`).

Are you saying that make-frame-on-display works differently under
Wayland?

> > How do we know whether a particular frame should or shouldn't have the
> > 'environment' frame parameter?  When the frame is created by the
> > server on behalf of a client, we know.  But for a random
> > frame-creation function, how do we know?
> 
> That's a tricky question.  In my understanding, it makes sense in an
> ancestor/child relationship: if the ancestor of FRAME has some distinct
> set of environment variables, we copy them to the new frame.

What is the "ancestor frame"?  We don't have such relationships
between frames.

And if you mean the frame that was the selected on when the other
frame was created, I'm not sure I agree that this is an indication of
whether environment should be copied.

But let's hear what others think about this.

> To clarify all my assumptions, I understand that the `environment`
> property exists because frames of the same daemon or server can appear
> in very different environments, like multiple X or Wayland servers,
> terminals, remote sessions, and so on.

No, it's because starting a client frame is supposed to be similar to
starting an Emacs from the same terminal.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Thu, 15 Apr 2021 22:29:01 GMT) Full text and rfc822 format available.

Message #17 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Thibault Polge <thibault <at> thb.lt>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 47806 <at> debbugs.gnu.org
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Fri, 16 Apr 2021 00:27:59 +0200
> Are you saying that make-frame-on-display works differently under
> Wayland?

AFAIK Emacs doesn't support Wayland yet (unless there's been work to
that end with GTK3?).  To show X programs, Wayland environments rely on
XWayland, an X server that runs as a Wayland program.  I this don't
believe that `make-frame-on-display` does anything different on Wayland,
but I suspect, to the contrary, that it's fully unaware that it's not on
a "real" X server. Or, maybe more accurately, that it has no access to
the underlying Wayland system, which I'm trying to reach.

> What is the "ancestor frame"?  We don't have such relationships
> between frames.  And if you mean the frame that was the selected on
> when the other frame was created, I'm not sure I agree that this is an
> indication of whether environment should be copied.

Yes, that's roughly what I meant by "ancestor".  I'd argue to the
contrary that this is a very good indication: those two frames run are
related, they should share their environment instead of the daemon's.
But perhaps my understanding of the problem is biased by my WM issues.

I meant something just a bit stronger than "was the selection", though.
In my idea, a new frame should inherit the selected frame's environment
if and only if it's being created by an interactive command call.  This
excludes, for example, frames created from idle timers, or through a
process filter or a sentinel.  This is because, IIUC, interactive
commands need to be called from a frame, so there's really a
nonambiguous "parent" there.

> No, it's because starting a client frame is supposed to be similar to
> starting an Emacs from the same terminal.

Thank you for that clarification.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Fri, 16 Apr 2021 06:06:02 GMT) Full text and rfc822 format available.

Message #20 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 47806 <at> debbugs.gnu.org
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Fri, 16 Apr 2021 09:05:45 +0300
> From: Thibault Polge <thibault <at> thb.lt>
> Cc: 47806 <at> debbugs.gnu.org
> Date: Fri, 16 Apr 2021 00:27:59 +0200
> 
> > What is the "ancestor frame"?  We don't have such relationships
> > between frames.  And if you mean the frame that was the selected on
> > when the other frame was created, I'm not sure I agree that this is an
> > indication of whether environment should be copied.
> 
> Yes, that's roughly what I meant by "ancestor".  I'd argue to the
> contrary that this is a very good indication: those two frames run are
> related, they should share their environment instead of the daemon's.
> But perhaps my understanding of the problem is biased by my WM issues.
> 
> I meant something just a bit stronger than "was the selection", though.
> In my idea, a new frame should inherit the selected frame's environment
> if and only if it's being created by an interactive command call.  This
> excludes, for example, frames created from idle timers, or through a
> process filter or a sentinel.  This is because, IIUC, interactive
> commands need to be called from a frame, so there's really a
> nonambiguous "parent" there.

I don't think I agree.  Interactive invocation could have several
layers before it comes to the frame-creation function.  For example, I
could imagine a command that eventually does

  (with-selected-frame FRAME
    (make-frame ...))

IOW, the frame that is the selected one when a command is invoked is a
very weak indication of any "parent-child" relationship.  I don't
think we have anything like that anywhere else in Emacs, except with
child frames.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Wed, 29 Jun 2022 11:11:02 GMT) Full text and rfc822 format available.

Message #23 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 47806 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Wed, 29 Jun 2022 13:10:00 +0200
Thibault Polge <thibault <at> thb.lt> writes:

>> Are you saying that make-frame-on-display works differently under
>> Wayland?
>
> AFAIK Emacs doesn't support Wayland yet (unless there's been work to
> that end with GTK3?).  To show X programs, Wayland environments rely on
> XWayland, an X server that runs as a Wayland program.  I this don't
> believe that `make-frame-on-display` does anything different on Wayland,
> but I suspect, to the contrary, that it's fully unaware that it's not on
> a "real" X server. Or, maybe more accurately, that it has no access to
> the underlying Wayland system, which I'm trying to reach.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Reading this bug report, it's not quite clear what the actual problem is
here.  In any case, Emacs 29 has pure GTK support (for Wayland), so
perhaps this isn't an issue any more?

If this is still an issue, could you provide a code snippet to reproduce
the problem, starting from "emacs -Q"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 29 Jun 2022 11:11:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Wed, 29 Jun 2022 11:16:01 GMT) Full text and rfc822 format available.

Message #28 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Thibault Polge <thibault <at> thb.lt>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47806 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Wed, 29 Jun 2022 13:15:37 +0200
> If this is still an issue, could you provide a code snippet to reproduce
> the problem, starting from "emacs -Q"?

I believe native Wayland support will make this issue irrelevant.

Best regards,
Thibault




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47806; Package emacs. (Wed, 29 Jun 2022 11:30:02 GMT) Full text and rfc822 format available.

Message #31 received at 47806 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 47806 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#47806: 28.0.50; `make-frame` frame should probably clone
 the `environment` parameter into the new frame
Date: Wed, 29 Jun 2022 13:29:44 +0200
Thibault Polge <thibault <at> thb.lt> writes:

>> If this is still an issue, could you provide a code snippet to reproduce
>> the problem, starting from "emacs -Q"?
>
> I believe native Wayland support will make this issue irrelevant.

OK; closing this bug report, then, I guess.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 47806 <at> debbugs.gnu.org and Thibault Polge <thibault <at> thb.lt> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 29 Jun 2022 11:31:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 28 Jul 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 245 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.