From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibault Polge Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <871rbbi3o0.fsf@thb.lt> References: <87k0p39zbo.fsf@thb.lt> <838s5jxt55.fsf@gnu.org> <877dl3ib4a.fsf@thb.lt> <835z0nxr0s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7897"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47806@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 16 00:29:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXAU2-0001uA-5w for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Apr 2021 00:29:10 +0200 Original-Received: from localhost ([::1]:33172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXAU1-0007YZ-9Y for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Apr 2021 18:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXATu-0007Xu-5p for bug-gnu-emacs@gnu.org; Thu, 15 Apr 2021 18:29:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lXATt-0007f7-Uf for bug-gnu-emacs@gnu.org; Thu, 15 Apr 2021 18:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lXATt-00047Z-Ro for bug-gnu-emacs@gnu.org; Thu, 15 Apr 2021 18:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thibault Polge Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Apr 2021 22:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47806 X-GNU-PR-Package: emacs Original-Received: via spool by 47806-submit@debbugs.gnu.org id=B47806.161852568915770 (code B ref 47806); Thu, 15 Apr 2021 22:29:01 +0000 Original-Received: (at 47806) by debbugs.gnu.org; 15 Apr 2021 22:28:09 +0000 Original-Received: from localhost ([127.0.0.1]:39471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXAT2-00046H-Sx for submit@debbugs.gnu.org; Thu, 15 Apr 2021 18:28:09 -0400 Original-Received: from 3.mo178.mail-out.ovh.net ([46.105.44.197]:51439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXAT0-000468-UH for 47806@debbugs.gnu.org; Thu, 15 Apr 2021 18:28:07 -0400 Original-Received: from player735.ha.ovh.net (unknown [10.108.4.73]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 29C40CB8A2 for <47806@debbugs.gnu.org>; Fri, 16 Apr 2021 00:28:04 +0200 (CEST) Original-Received: from thb.lt (lfbn-idf3-1-671-78.w86-252.abo.wanadoo.fr [86.252.240.78]) (Authenticated sender: thibault@thb.lt) by player735.ha.ovh.net (Postfix) with ESMTPSA id D1D8B1CE9B6E1; Thu, 15 Apr 2021 22:28:02 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-96R00196d071f6-264d-4d1c-8162-5e179c6b5658, 836A100A063FC8CC43F82078C8D23980AB49F331) smtp.auth=thibault@thb.lt X-OVh-ClientIp: 86.252.240.78 In-Reply-To: <835z0nxr0s.fsf@gnu.org> X-Ovh-Tracer-Id: 13687565171754518963 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrudelgedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufgjfhffkfggtgesthdtredttddttdenucfhrhhomhepvfhhihgsrghulhhtucfrohhlghgvuceothhhihgsrghulhhtsehthhgsrdhltheqnecuggftrfgrthhtvghrnhepfeduuddvvdduudduvddvjeefhfelgfeutddvgfejhfegteeihefhiefgveffvdffnecukfhppedtrddtrddtrddtpdekiedrvdehvddrvdegtddrjeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeefhedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehthhhisggruhhlthesthhhsgdrlhhtpdhrtghpthhtohepgeejkedtieesuggvsggsuhhgshdrghhnuhdrohhrgh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204102 Archived-At: > 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.