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 17:55:36 +0300 Message-ID: <86ttgibxqv.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22728"; 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 Sun Jul 21 16:56:26 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 1sVXz7-0005ib-WF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Jul 2024 16:56:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVXyl-0001hH-OK; Sun, 21 Jul 2024 10:56: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 1sVXyj-0001gr-Gv for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 10:56:01 -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 1sVXyj-0001Sy-29 for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 10:56:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sVXyk-0007oB-Qg for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2024 10:56: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 14:56: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.172157375029979 (code B ref 71866); Sun, 21 Jul 2024 14:56:02 +0000 Original-Received: (at 71866) by debbugs.gnu.org; 21 Jul 2024 14:55:50 +0000 Original-Received: from localhost ([127.0.0.1]:55805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVXyY-0007nS-8B for submit@debbugs.gnu.org; Sun, 21 Jul 2024 10:55:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sVXyW-0007mv-9z for 71866@debbugs.gnu.org; Sun, 21 Jul 2024 10:55:49 -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 1sVXyL-0001RN-ST; Sun, 21 Jul 2024 10:55:37 -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=O3AsSyoUo49NPL26EaIieSLeE1UGx1/S6xiSR4eSovk=; b=TkDQ0ou95zi4 3yI9EAeJfLv55wbIEu3S6tXMYKVex8eUiPgwrYeYeDHpUj/RHLiD6Dae5z8//+8V1xtYQswAigq4s YKavR9oZO2dAI+7OM5HguLB6X1XS8fLJddZYN8rAe857Kn3XZClEK+Bj9Y6npfrJx3KdPXT+9gq5o 1+xGJa+NTSPJtyoMBroOJGNXcWWHk1Mj69x4J9TR08bzhN6nzoIhnnqdNdRKvCj/ML02MXoLeByg0 NKN/mQssYkFS4T7EHGbJwG1PNIhy1jx3JbWrdY6YzgFpw7Wwbu3pmASO71x4r9Xh+HaMDA5RL8EdP zEVO0WgBNGp+sCB8bv5UDg==; In-Reply-To: <1659357b-5ca0-47a6-8ff3-4aa26017280b@gutov.dev> (message from Dmitry Gutov on Sun, 21 Jul 2024 16:50:18 +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:289076 Archived-At: > Date: Sun, 21 Jul 2024 16:50:18 +0300 > Cc: 71866@debbugs.gnu.org > From: Dmitry Gutov > > > . 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. > > I can repeat the experiment, but in my testing the problem only occurs > in (all) frames other than the first/original one, regardless of their > positioning. I believe you. But I want to see both cursors, because they are usually redrawn in tandem. > Also FWIW it doesn't matter whether the frames display the same buffer > or different ones. Yes, I know. > > . 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. > > . 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. > > That's 'other-frame', bound to 'M-`'. OK. > > . 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. > > Would you like to see all the other backtraces, or some specific ones? 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. > In the former case, that will be a lot of text to sort through. Yes, but it is imperative to see all the calls. > > 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. > > ...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. > >>> 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. > > Maybe I'll ask some questions later, which I know what to ask. I can > understand some high-level things from the backtrace already, but the > devil is in the details. Eventually, if and when we find the call which causes this incomplete redraw, you will need to step through the code and see what happens there. When we get there, I will try to explain the main ideas of the code. Thanks.