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

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

[Thibault Polge]

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

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

[Eli Zaretskii]

> From: Thibault Polge <thibault@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?

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

[Thibault Polge]

> 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

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

[Eli Zaretskii]

> From: Thibault Polge <thibault@thb.lt>
> Cc: 47806@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.

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

[Thibault Polge]

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

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

[Eli Zaretskii]

> From: Thibault Polge <thibault@thb.lt>
> Cc: 47806@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.

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

[Lars Ingebrigtsen]

Thibault Polge <thibault@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

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

[Thibault Polge]

> 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

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

[Lars Ingebrigtsen]

Thibault Polge <thibault@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