From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: "Final" version of tty child frames Date: Wed, 8 Jan 2025 10:56:31 +0100 Message-ID: <19ca4d76-cd63-4abe-8c8d-ca85c4d15ef2@gmx.at> References: <86wmi0g0x6.fsf@gnu.org> <11a86987cce9fe0a257c3fa58703dc33@finder.org> <86wmgl6jzv.fsf@gnu.org> <092cb755eee3a9b5e06d15c0b07e90b1@finder.org> <276414b03c24964aaeb9e43e8dba5e77@finder.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31465"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 08 10:57:36 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 1tVSoh-000834-QT for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Jan 2025 10:57:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVSns-0001ys-Q1; Wed, 08 Jan 2025 04:56:44 -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 1tVSnr-0001yi-Kp for emacs-devel@gnu.org; Wed, 08 Jan 2025 04:56:44 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVSno-0006x2-D7; Wed, 08 Jan 2025 04:56:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1736330192; x=1736934992; i=rudalics@gmx.at; bh=VXiNFdQE9pjn7kA5qaFoh9rbPoiN8mq2xI2FoLf+tqw=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=sYnVem1udrXi2b/fUr5I3VymGqZU2IBo/ifK3W9H6CWyK8I6hZeJR3bWfqTzq0GB xmDbOU+pqudZl1zySKQyaSBlnjQx3C4NYrWxepBD40sTbzCR5xR7M9WsZ/2Co8bTr F5yQpDG5FhNUi0peY4bw6835LMGG/uOdY+id1i89Jdjv2tqqngmUBwXX7neFivfVO ARwb/bbI8X7xg4z94aqzFfqOH7huElmIHINgG7GwxAysRsobKQsHQVXgeNQEd9d/E s7AesmuzAouuyU0fe6fqZ6RRZ6ADLh7f2w1Kbburoo4oDWnVHMtS0ubT7XFPxDys0 lyLCuyYuq5AIzjbftg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.183]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mw9Q6-1tm2DM2Kxw-011iih; Wed, 08 Jan 2025 10:56:32 +0100 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:XKuTwq9ekdWl4OQSXcgmkIO3609D5pgsSsFSz/gfeL1HpO3vOvH 5uKnGw+LRhINWM4umGjrvO02ZRjuyMKFOVY5ahQeiiUJ+ZOCh3+kzpnNCj2crnDuak3JH9l Ft8sGNTbxGD1WKJXQoeSRK80FrFwfSWhahwgcKqx2mKCFkx7/6tKMKw9WQfg54M852ACR7p VNtAR15S086Kvliu30NOA== UI-OutboundReport: notjunk:1;M01:P0:IPnxXeBXp6w=;ImcUyzRSoWIczosmPeFLwhsEEyx LA6CuEAw21/erIAH7xzdd8w0XHledXtIhpWFcErN82mHko2Fh8lYfVZE7w/lhh4scQ+tlhiph JqxIH9cORLbdNYsMFAKDN5ekB+Wrt1gZ6wT5lAU3jgkytvo278s3H4hsweVXZye01TwGkwJzH NGicXed2e20u/KwniyUXqE5phZ/sAlPwEg1eKYwW1JmCo7+VUPxQoqgYzwZaTLEvUleXglrDG p+j8r7lxEzORjKn3Z4KcaV3QXldk0/j2eWkHB8bE9zSZgrACw4YKBbhtCmWJuLeq+8xe2rJ8l iTBWTZGBu1lEnvs+F/lrVROwS/TqNcK/vun9jr+pPJSR5Nhus+yT+W14C8nFhrftf016FrBya 33cpE9GyheOlBD9mycujGnW6uQpTyzJDuiOMjx37yjW6GHkoxpyyse8o3BvNmrVDzpIDHxGQ1 qqepAb+jckRenPQGSnPU1rBbreAeLpAXX6hXphBDd1qYj7wXGGJeVWFx5sEH1+tKYaY3gT4sj Cat2TJQJ5C21NaiCDVA9Me9SYhKka9X2xcpEOzDfUFx9BT+rHisOucSoFROdqnewhNpDzhf2K WvUM7xvQWFZ/NVZWI+ItJ1oy3PgHEKvNQPFb684D2iRegHP+akSBZY1AvCcmEqdASDPnSKXaj JS6mV/eDgQ1qtpJuDeGfVZkhXhZzz/wLqnnxxFqr9rIh8Y7IYZVDWpLeajuLtnPUhv1XnAXjz Fphsbwm2hEV8/5iBF8/drRcAqlk2xeV/n+5FSNowsKWmH9+utcPX7VL7I7JMQomnopplQUId Received-SPF: pass client-ip=212.227.15.19; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, 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:327782 Archived-At: >> If you have the time, please also try to look into two issues I raised >> earlier: >> >> Two further things I noticed: When point in the parent frame is >> effectively hidden by the child frame, its cursor sometimes appears at >> the right of the child frame and sometimes it's not shown. I have not >> understood the underlying principle for this behavior. Also when the >> selected region in the parent frame is active, its overlay covers the >> child frame. That's ugly. > > TTY child frame cursors behave even worse under GPM and a TERM=linux > terminal. In this case, the cursor ends up on some lines always > appearing at the end of lines (ignoring separate frames or windows) > and sometimes in the right place. The point position is correct > though and the cursor does appear correctly once I start pressing > simple keys like 'A'. Both issues I raised above seem to be gone with master I pulled today. Thanks for fixing them. One thing I noticed is that with code like the following (defvar tty-child-frame nil) (defvar tty-child-buffer (get-buffer-create "*tty-child-buffer*")) (defvar tty-child-window nil) (defun tty-make-child-frame () (interactive) (setq tty-child-frame (make-frame `((parent-frame . ,(selected-frame)) (left . 20) (top . 10) (width . 0.3) (height . 0.8) (border-width . 0) (background-color . "yellow") (tool-bar-lines . 0) (menu-bar-lines . 0) (minibuffer . nil) (no-special-glyphs . t) ))) (setq tty-child-window (frame-root-window tty-child-frame)) (set-window-buffer tty-child-window tty-child-buffer) (set-face-background 'internal-border "blue" tty-child-frame) (set-face-background 'child-frame-border "blue" tty-child-frame)) (defun tty-toggle-child-frame () (interactive) (if (frame-live-p tty-child-frame) (if (frame-visible-p tty-child-frame) (make-frame-invisible tty-child-frame) (make-frame-visible tty-child-frame)) (tty-make-child-frame))) (defun tty-switch-to-child-frame () (interactive) (if (frame-live-p tty-child-frame) (if (frame-visible-p tty-child-frame) (if (eq tty-child-frame (selected-frame)) (select-frame-set-input-focus (frame-parent tty-child-frame)) (select-frame-set-input-focus tty-child-frame)) (make-frame-visible tty-child-frame) (select-frame-set-input-focus tty-child-frame)) (tty-make-child-frame) (select-frame-set-input-focus tty-child-frame))) then when I first evaluate 'tty-toggle-child-frame' followed by 'tty-switch-to-child-frame' and I start typing I get an assertion failure with a backtrace like the below #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432 #1 0x0000000000699b76 in die (msg=0x7dfc63 "FRAME_VISIBLE_P (root)", file=0x7df29f "../../src/dispnew.c", line=3962) at ../../src/alloc.c:8059 #2 0x0000000000427575 in combine_updates_for_frame (f=0x18662e0, inhibit_scrolling=false) at ../../src/dispnew.c:3962 #3 0x00000000004832fc in redisplay_internal () at ../../src/xdisp.c:17699 #4 0x0000000000483719 in redisplay_preserve_echo_area (from_where=8) at ../../src/xdisp.c:17835 #5 0x000000000060b715 in detect_input_pending_run_timers (do_display=true) at ../../src/keyboard.c:11579 #6 0x00000000007465d9 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at ../../src/process.c:5856 #7 0x0000000000430243 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at ../../src/dispnew.c:6889 #8 0x00000000005f6383 in read_char (commandflag=1, map=XIL(0x7ff1fcdf4053), prev_event=XIL(0), used_mouse_menu=0x7ffc85a5703f, end_time=0x0) at ../../src/keyboard.c:2925 #9 0x00000000006097f3 in read_key_sequence (keybuf=0x7ffc85a571f0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at ../../src/keyboard.c:10746 #10 0x00000000005f1c46 in command_loop_1 () at ../../src/keyboard.c:1424 #11 0x00000000006d06e3 in internal_condition_case (bfun=0x5f1817 , handlers=XIL(0x90), hfun=0x5f0c99 ) at ../../src/eval.c:1607 #12 0x00000000005f13de in command_loop_2 (handlers=XIL(0x90)) at ../../src/keyboard.c:1163 #13 0x00000000006cfb39 in internal_catch (tag=XIL(0x122d0), func=0x5f13b4 , arg=XIL(0x90)) at ../../src/eval.c:1286 #14 0x00000000005f1370 in command_loop () at ../../src/keyboard.c:1141 #15 0x00000000005f073b in recursive_edit_1 () at ../../src/keyboard.c:749 #16 0x00000000005f0967 in Frecursive_edit () at ../../src/keyboard.c:832 #17 0x00000000005ec1cd in main (argc=5, argv=0x7ffc85a57828) at ../../src/emacs.c:2636 Lisp Backtrace: "redisplay_internal (C function)" (0x0) 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. What's the purpose of creating a new top frame without minibuffer here? We end up with three frames - the initial one, the child frame and the new root frame without minibuffer. redisplay_internal eventually detects here Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf); struct frame *mini_frame = XFRAME (WINDOW_FRAME (XWINDOW (mini_window))); if (mini_frame != sf) that the mini_frame is not the selected frame { XWINDOW (mini_window)->must_be_updated_p = true; update_frame (mini_frame, false); if (is_tty_frame (mini_frame)) combine_updates_for_frame (mini_frame, false); and the call here crashes because mini_frame is the old root frame but that frame's visibility has been set to false by the code above. martin