From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: "Final" version of tty child frames Date: Wed, 08 Jan 2025 11:29:06 +0100 Message-ID: References: <86wmi0g0x6.fsf@gnu.org> <11a86987cce9fe0a257c3fa58703dc33@finder.org> <86wmgl6jzv.fsf@gnu.org> <092cb755eee3a9b5e06d15c0b07e90b1@finder.org> <276414b03c24964aaeb9e43e8dba5e77@finder.org> <19ca4d76-cd63-4abe-8c8d-ca85c4d15ef2@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="707"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jared Finder , Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 08 11:30:18 2025 Return-path: Envelope-to: ged-emacs-devel@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 1tVTKM-000Abt-GW for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Jan 2025 11:30:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVTJM-0006ZE-Kp; Wed, 08 Jan 2025 05:29:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVTJK-0006Yk-JX for emacs-devel@gnu.org; Wed, 08 Jan 2025 05:29:14 -0500 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tVTJI-0000tR-LA; Wed, 08 Jan 2025 05:29:14 -0500 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d3d479b1e6so23690887a12.2; Wed, 08 Jan 2025 02:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736332148; x=1736936948; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=54t9g3Egc90hHjziTAWt2sf0aRlzkPYG8RlmL3517NU=; b=nYdV6UrOkO9gk4WaSSGmerRBAjnB2cKStJW76VYywEDOGZDgvKfFuyAPqCnlgH/UJV OvKZFGsMtdQlDkiW2Dpbj1/CKwJ+poOgxaPc7uZEqjQH58j3gjWO/9UDabIV/7n5eKrC oLlObbSwxU8z/Kbr8wvVM0ZBipM07gqwdIuH8s7JEPxvk0pehsgf5HOOffZ+/HwHKLnv TZ426yfxPNRQtWzXHy4NiaFb/wf/FMl2OSH5Kmk63cFHjeIGNyf06F5wxSnkVaGmv+rQ 3yi3CoJJNVeoUfa8xiOsD/9DEqF3nX7wgQnRFuk7SyblD+o2UzYmIO2GfFFa0FSS0OAq WHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736332148; x=1736936948; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=54t9g3Egc90hHjziTAWt2sf0aRlzkPYG8RlmL3517NU=; b=wOd3pzeHHYCG8fgIqlL3QqTARG7QUtzJnCD+DTpu0tDVPSmT7zUpD7Q2GMwxM9mBvh HXRfmBa3jtfq3NM5WUd1TDW4xM8bCqG8lFiXhm9BseDTVjK7DxMvmz5/SGZNjdY4yYd8 HrmySe+/P5E1jY6yC1lWFOu/lpQpDbbIe2B4x2KmunPfA4Oi8tHogVQvIBk/pdq7p9+q 6kilf+TJA9MPK/aN4YtUCwSvq4pLjxfHFB9tmqTmP8NB+ewA+iCyETXryjsuJtL3cVxB aMXRPszzRnntYLRtHgS6872A1J3McXjlhL51JqDjK3CkcgqXlihKXnKBk8J0JaPyEVup T5vQ== X-Forwarded-Encrypted: i=1; AJvYcCVhIHf/lL4A8Xjw530yXoqKz48xDYjedusEA3uVdQTgliB0XHCsYDjLSkElPhmvzqyXNEsy@gnu.org, AJvYcCWFeDlYDpGtRwbGY9JZEnEHgJ+cDvNl3ldceOWgOoyItkYAxMkYB4pq56RaqqzQpvOevGsSZqnj9K6On0o=@gnu.org X-Gm-Message-State: AOJu0YySK5KrxwWDx93ID1VFOJ58yQhwkFyKwcG0YRXQFgtjKPMlGU3v ofHHIJn9Ma8m4uTjCHnWW66mVmAeVI0q16Sfc/Q/w2WaCjLW5N8aZtzS0rtW X-Gm-Gg: ASbGnct0zm/5yjyPKb1pfZV8LFSgjQPy9n02TpW79uOaL0xbxGmLsTt70hWkUlSz2ph Piw+xVVpjJjNgyW75zMcQlP1vmXNWSifWSI90wHf2BNdZcNbAnQoEpUcetFKZI7eNNeQlINM8iF /CAZ7qabl6XAGrU8hct3I+99+l9dZO4MP4lPtnPZ2qZ54nbDB5exxa1gC9EGvL2tUW4teUCUbaa i8tzhI3QJ+vitLqSTLoC66x/R8iB59qTq6W/WyRr3ecX4bONpn0XePXZ6+kI2tff43b3T5cs2sW Geozz81aQt/bMA4vFVYh57L2A64/DQz3dyALZAUuAwgx8nP6UdoRj+l/J3DZcuER X-Google-Smtp-Source: AGHT+IGMXX4Coeywy7K9Yx9yZUSobuC45ZskhzTwyMLbAsJ9Nl19spOAydSuV6nZFw52jeD8dm2Uvw== X-Received: by 2002:a05:6402:5194:b0:5d0:fb56:3f with SMTP id 4fb4d7f45d1cf-5d972e0e341mr4458472a12.12.1736332147670; Wed, 08 Jan 2025 02:29:07 -0800 (PST) Original-Received: from pro2 (p200300e0b70e79000ca159a4b0b99ee2.dip0.t-ipconnect.de. [2003:e0:b70e:7900:ca1:59a4:b0b9:9ee2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e8951ebsm2465493466b.71.2025.01.08.02.29.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 02:29:07 -0800 (PST) In-Reply-To: <19ca4d76-cd63-4abe-8c8d-ca85c4d15ef2@gmx.at> (martin rudalics's message of "Wed, 8 Jan 2025 10:56:31 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327783 Archived-At: martin rudalics writes: > The cause is that my 'tty-make-child-frame' has > > `((parent-frame . ,(selected-frame)) > ... > (minibuffer . nil) > > but the consequences are completely unclear to me. What happens is that > make_terminal_frame has this > > if (EQ (mini, Qnone) || NILP (mini)) > f = make_frame_without_minibuffer (Qnil, kb, Qnil); > > which reenters make_terminal_frame and does > > if (FRAME_LIVE_P (root)) > SET_FRAME_VISIBLE (root, false); > > for the old selected "root" frame. Guess that wasn't what I intended :-). > What's the purpose of creating a new top frame without minibuffer > here? The frame from make_frame_without_minibuffer is supposed to become a child frame at bit later if (f == NULL) f = make_frame (true); f->parent_frame = parent; ^^^^^^^^^^^^^^^^^^^^^^^^ > We end up with three frames - the initial one, the child frame and the > new root frame without minibuffer. redisplay_internal eventually > detects here I've not yet understood where the third frame is created. Probably have to see this in the debugger to get into this again. Could you please submit a bug so that I don't forget looking into this?