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: Sun, 21 Jul 2024 10:20:19 +0300 Message-ID: <86cyn7cito.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34879"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71866@debbugs.gnu.org To: Dmitry Gutov , Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 21 09:21:29 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 1sVQsq-0008y0-SD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Jul 2024 09:21:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVQsR-0008QX-Hu; Sun, 21 Jul 2024 03:21:03 -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 1sVQsP-0008QC-Vi for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 03:21:02 -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 1sVQsP-0000X0-NZ for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 03:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sVQsP-0007BY-VN for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 03:21: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: Sun, 21 Jul 2024 07:21: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.172154643327569 (code B ref 71866); Sun, 21 Jul 2024 07:21:01 +0000 Original-Received: (at 71866) by debbugs.gnu.org; 21 Jul 2024 07:20:33 +0000 Original-Received: from localhost ([127.0.0.1]:54672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVQrw-0007Ab-VH for submit@debbugs.gnu.org; Sun, 21 Jul 2024 03:20:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVQru-0007AL-OA for 71866@debbugs.gnu.org; Sun, 21 Jul 2024 03:20:31 -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 1sVQrl-0000Oz-QR; Sun, 21 Jul 2024 03:20:21 -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=TaGzdJEEomrJGo7Z2Cxc6aHVXSc//aQG3PeOPeQhPKc=; b=HaK26sCvydwV NjEV6ptzelAej1ox1A0Ew7OkC6CaXPG88NtrU48+pjueKpo/ZUebJL6+7XFUum6sNFn+wqQVBVdTT CHY+8zWri7vCUffqIKiOkcQT0RQ+9rinKZvbz5PuofNTk76nHBUnE5TO+F1sN7iBP70XdsZE0WiUa KtfvznI36JqluZ5fs0lI14x7kB0zF2rilnWqZt/GnYKfonom+I95IKyaArZIYb42baocW1Tv9t15q 37+0RsHk1ORv4Nnmx7hrkhPS+Y8PBakfSXDY90v7/oGG9/HGtYQydgbik3rvHyA7JQ7wAHUXywFeY BJ1DS/uS2+fx/y3Q0Yts2A==; In-Reply-To: (message from Dmitry Gutov on Sun, 21 Jul 2024 03:53:26 +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:289059 Archived-At: > Date: Sun, 21 Jul 2024 03:53:26 +0300 > Cc: 71866@debbugs.gnu.org > From: Dmitry Gutov > > Perhaps it'll be easier to share a video. Sorry, it's a large file, so I > just uploaded it to a free online hosting: https://streamable.com/d6775w > > The first (smaller) part is me reproducing the bug, then I switch to the > terminal emulator, enable the breakpoint and demonstrate how the > behavior of the same command (other-frame) changes. > > After the video was finished, I also repeated the same scenario, and > saved the backtrace of the last (12th) breakpoint hit. Thanks. The video shows some parts of the problem, but not enough details. It doesn't help that I don't know enough about the macOS GUI system and conventions. Here are some details that I'm missing: . The two frames are arranged in a way that the cursor in the left-most frame is not really visible when the right-most frame partially obscures it. So it's hard to tell at all times what kind of cursor (or no cursor) is shown in that frame. Could you please repeat the experiment after moving the right-most frame a bit to the right, so as not to obscure the cursor of the other frame? IOW, I'd like to be able to see cursors in both frames regardless of which frame is selected/has focus. . 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? . What exactly are you doing with keyboard or mouse in the first part, where you quickly alternate the frames? All I see is the initial mouse click inside the left-most frame, but the subsequent changes seemingly happen "by themselves", without any visible trigger. . The backtrace indicates that ns_draw_window_cursor is called from windowDidResignKey, which AFAIU is called when the focus changes. For some reason, display_and_set_cursor, which calls ns_draw_window_cursor, decided that cursor type should be NO_CURSOR, although gui_update_cursor was called with cursor_on_p=true, and the question is why? You don't show any other backtraces, although in the video I clearly see them, and they use other values of cursor type. In addition, I don't know which window passed to ns_draw_window_cursor (the 'w' argument) belongs to which frame, and without that, it is very hard to interpret the data of the debugging session, because I need to compare the calls with what I see in the Emacs frames. IOW, the important question is: was the problematic display, where no cursor is shown, caused by an incorrect call to ns_draw_window_cursor, or was it caused by some other factor? The data and the video you presented does not allow to answer this questions. Adding the missing details I mentioned will probably help answer them. > > But anyway, if this is the same scenario, then why are you only > > looking at what happens inside ns_draw_window_cursor? Redrawing the > > block cursor involves displaying the character under cursor with > > special colors, and ns_draw_window_cursor is just the beginning: it > > calls other functions which actually do the job. > > More breakpoints means more chances for the behavior to change. I also > don't really know which other places to look at. Stepping through all > the callees is both time-consuming and something that is unlikely to > help until I manage to read all of the underlying implementation and > start making sense of the data that's being used, to be able to notice > when this or that variable has an odd value. I can explain the overall logic of the implementation if it can help. > But maybe at this point some print-debugging might be more beneficial > (since that shouldn't change the existing behavior). See the linked > video and the attached backtrace, though. At this point, I'm not yet sure printf-debugging could help. Maybe later. Thanks. P.S. I've added Alan to this discussion, in the hope that he could help with understanding what is going on here.