From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization Date: Mon, 22 Jul 2024 16:27:30 +0100 Message-ID: References: <56cc929b-5491-4ed4-a527-d0b1a369e625@gutov.dev> <86o76sea9d.fsf@gnu.org> <72a0b2e2-600e-46f1-b583-0bed86f27d2d@gutov.dev> <86o76scaou.fsf@gnu.org> <86cyn7cito.fsf@gnu.org> <1659357b-5ca0-47a6-8ff3-4aa26017280b@gutov.dev> <86ttgibxqv.fsf@gnu.org> <7ae61592-8319-4b1a-b973-4015ff1db569@gutov.dev> <86wmlda3jb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , 71866@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 22 17:28:19 2024 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 1sVuxW-0001ET-JK for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Jul 2024 17:28:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVuxE-0002JX-Ly; Mon, 22 Jul 2024 11:28:00 -0400 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 1sVuxD-0002Ic-C2 for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 11:27:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sVuxD-0008SG-3x for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 11:27:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sVuxF-0005bo-VI for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 11:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Jul 2024 15:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71866 X-GNU-PR-Package: emacs Original-Received: via spool by 71866-submit@debbugs.gnu.org id=B71866.172166206521528 (code B ref 71866); Mon, 22 Jul 2024 15:28:01 +0000 Original-Received: (at 71866) by debbugs.gnu.org; 22 Jul 2024 15:27:45 +0000 Original-Received: from localhost ([127.0.0.1]:58446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVuwz-0005b9-4M for submit@debbugs.gnu.org; Mon, 22 Jul 2024 11:27:45 -0400 Original-Received: from dane.soverin.net ([185.233.34.30]:39759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVuwv-0005ap-Vc for 71866@debbugs.gnu.org; Mon, 22 Jul 2024 11:27:43 -0400 Original-Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4WSPKc2dlCz2yKD; Mon, 22 Jul 2024 15:27:32 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4WSPKb6py5zCw; Mon, 22 Jul 2024 15:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1721662052; bh=m+EYELYALhljekCn71sJfNJ1b+X3fWDN9uW0MCBzZO8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Hk42NM1uWXx62aQDlVRKli6YX3QV7jVbcnDycY7u/EB7ZNPOpi5vFuaNgU9cKEwUd 7VjreclZM9+m/0fvql00J4VzTQGYOG2PKh519MdCsX/izxH4Ju2U5IROdcZeXdW2uE nhGa+smXdn1JXudLga8xxhddz94bMztvDOu6FoYXlvKLVpJj9uKoz/nScZit22bw8K 8a7zr+yYZ/aj84/IsreKQXS1cEq6RTdgcuqisYjKM6dTjIDMMKICcg+E47eK4kiX6+ bIsqGb0/m5OkBxfkmEiQO8XnkU8mkODOaZ0kRz/UyS6gKFX8D8W8HDLv7q10lAjRqu 62X9/9l0mXk7g== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.97) (envelope-from ) id 1sVuwk-00000001YUL-3lGI; Mon, 22 Jul 2024 16:27:30 +0100 Mail-Followup-To: Alan Third , Eli Zaretskii , Dmitry Gutov , 71866@debbugs.gnu.org Content-Disposition: inline In-Reply-To: <86wmlda3jb.fsf@gnu.org> X-Spampanel-Class: ham 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:289119 Archived-At: On Mon, Jul 22, 2024 at 05:45:44PM +0300, Eli Zaretskii wrote: > > Thanks. There's a disturbing discrepancy between what the debugger > says about the calls to ns_draw_window_cursor and what I see on > display. For example, there are only 2 events where one of the two > Emacs frames begins showing a filled-block cursor (from some other > cursor display): at step "1" and step "3". But the backtraces you > collected tell a different story: the only calls with > FILLED_BOX_CURSOR are at steps "1" and "7". At step "3", the debugger > claims we called ns_draw_window_cursor with NO_CURSOR, whereas the > video clearly shows that the cursor is drawn as a filled block! This > issue alone already makes all this quite mysterious and hard to > interpret. > > Moreover, the only event in the video where a previously-displayed > cursor disappears in one of the windows is the last part, where you > type "c" and the debugger says "Process 7616 resuming". And that > happens without ns_draw_window_cursor being called! > > So I think there's some factor at work here that we are not > considering. Perhaps it's the macOS window-system or something. Hi Eli, The macOS display system is inherently double buffered, so there's no way to draw directly to the screen. This means any action taken won't be displayed on the screen until the NS run loop has run at least once. That occurs in the ns_select and ns_read_socket functions. > > > Could be, but in general ns_draw_window_cursor is AFAIK the only way > > > of redrawing the cursor, so I think we are on a good track here. > > > > Here's hoping. > > I'm no longer so sure about the above assertion, sadly. AFAIK it's the only way of *drawing* the cursor, but it's certainly possible that something else is *clearing* that space and not redrawing the cursor. Unfortunately I've no idea what that might be. I had a bug open myself about a very similar problem, possibly the same problem, but I closed it years ago because it just disappeared and nobody else had ever reported anything similar. I was never able to get to the bottom of it. -- Alan Third