bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]