[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47806: 28.0.50; `make-frame` frame should probably clone the `enviro
From: |
Eli Zaretskii |
Subject: |
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@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.