From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 17:45:44 +0300 Message-ID: <86wmlda3jb.fsf@gnu.org> References: <86frstfiop.fsf@gnu.org> <03b9a1c2-986d-40ea-bdd6-d13b419c9aa0@gutov.dev> <86v81i526t.fsf@gnu.org> <1f5f741f-d599-4051-8a34-27d349360eb8@gutov.dev> <86sewiztr2.fsf@gnu.org> <867cdto3uk.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26779"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alan@idiocy.org, 71866@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 22 16:47:34 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 1sVuK5-0006mP-FT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Jul 2024 16:47:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVuJh-00036d-Vf; Mon, 22 Jul 2024 10:47:09 -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 1sVuJY-00036D-Oy for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 10:47:00 -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 1sVuJX-0000R4-Cx for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 10:47:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sVuJa-0004UR-A1 for bug-gnu-emacs@gnu.org; Mon, 22 Jul 2024 10:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Jul 2024 14:47:02 +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.172165956417174 (code B ref 71866); Mon, 22 Jul 2024 14:47:02 +0000 Original-Received: (at 71866) by debbugs.gnu.org; 22 Jul 2024 14:46:04 +0000 Original-Received: from localhost ([127.0.0.1]:58422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVuId-0004Sv-Ux for submit@debbugs.gnu.org; Mon, 22 Jul 2024 10:46:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVuIa-0004SN-Bc for 71866@debbugs.gnu.org; Mon, 22 Jul 2024 10:46:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sVuIQ-0000O2-F1; Mon, 22 Jul 2024 10:45:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+3sX4Y0Vm7tFrXflp+vfoeoEbFUzANb5UcuT1J+aLjY=; b=GGlTQOVataxN f7WahUf+ymb5vZT8tDaCmcMYCsScAPmv41eRmXxIrHr/O1PRtgoFlAod3ekmCA0+oNIKEs6PrQyBR mvCFzqcRng5CGsw3Ntv+rq7EJbbkVnHpaiEXCOwBrZrJB3j/SrFK3phm3s3CTFalKXya/OWbA+G2N ks25srsed0NXyDBC66Ccnaq1cyv1MA5aVMGyvTnR448e6Xmc8i6PwWwbsbLTAqgHqVs5I1wj87hE7 jAe9HNyMK3D5yHrqMfleE2Pi8hUK7WDzpU5AaPLZBCPunxGBSAqIbIVAx1G8Ip8IqaGd8k6ojHJmv qllRDqDYa61rKIyDTp04AQ==; In-Reply-To: <7ae61592-8319-4b1a-b973-4015ff1db569@gutov.dev> (message from Dmitry Gutov on Mon, 22 Jul 2024 02:58:33 +0300) 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:289117 Archived-At: > Date: Mon, 22 Jul 2024 02:58:33 +0300 > Cc: alan@idiocy.org, 71866@debbugs.gnu.org > From: Dmitry Gutov > > >>> . Sometimes an Emacs frame shows its window as selected (judging by > >>> the way the mode line is displayed), but the 3 colored circles at > >>> the top left corner of the frame are shown in gray. What does > >>> this mean, in Emacs terms, and how is that different from the > >>> situation where both the mode line is shown as active and the > >>> circles are shown in red/yellow/green colors? > >> > >> It seems to me a consequence of our having a breakpoint inside a > >> function that updates how the frame looks (which includes its contents, > >> the "selected" status and etc) - when I switch the focus away manually > >> to a different program in the middle of that (to handle the breakpoint), > >> probably that created a de-synchronization that never happens in other > >> circumstances. > > > > If you are sure that this happens only when Emacs is stopped at a > > breakpoint, this aspect of the issue can be disregarded. > > Seems so to me. You could see the way Emacs behaves without breakpoints > at the beginning of the previous video. But note that both at the beginning of this new video and at its end, where the debugger says "resuming" (which means Emacs is running), the 3 circles of both Emacs frames are gray. So I guess (a) this does happen when Emacs runs, and (b) it probably means focus is in some other window, not in any of the Emacs frames. > > All of the backtraces from all the calls produced by a single M-` > > press. It is best to have only the backtraces that happen when the > > problem with the cursor is visible, if you can easily arrange for > > that. > > Yup, done that, see below. 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. I also don't understand the calls where cursor_type=NO_CURSOR, on_p=true, and active_p=false. I would expect to see HOLLOW_BOX_CURSOR there, because these are the calls where we display the cursor in a non-selected window. Could you step inside get_window_cursor_type and see how this happens? To arrange for that, get to the step before the one where the breakpoint in ns_draw_window_cursor will break with the above combination of arguments (for example, get to step "3" in your session), then add a breakpoint in display_and_set_cursor, trigger the next cursor display by typing "continue", then step through display_and_set_cursor and into get_window_cursor_type, and see why we end up deciding to display NO_CURSOR in that case. Also, what are your values of cursor-type and cursor-in-non-selected-windows? > >> ...and whether that all is a red herring, caused by our breakpoints, > >> whereas the code reading to the original problem might reside somewhere > >> else. ;-( > > > > 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. Thanks.