From: Dmitry Gutov <dmitry@gutov.dev>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 71866@debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Wed, 10 Jul 2024 05:46:35 +0300 [thread overview]
Message-ID: <d67cdfa2-dc75-4d58-8f82-49ddc55f5e45@gutov.dev> (raw)
In-Reply-To: <86sewiztr2.fsf@gnu.org>
On 09/07/2024 14:31, Eli Zaretskii wrote:
>> Date: Tue, 9 Jul 2024 05:37:10 +0300
>> Cc: 71866@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> For starters, put a breakpoint in ns_draw_window_cursor and see if it
>>> gets called in the scenario where you see the problem.
>>
>> Thank you.
>>
>> It does get called. Unfortunately, as soon as I put a breakpoint there,
>> any attempt to switch to the Emacs window drops into the debugger again
>> - and I have switch back to the terminal emulator to enter 'c RET' 20
>> times or so.
>
> I don't think I understand what you are trying to do. I thought you
> needed to "switch to the Emacs window" just once: to trigger the
> situation which you want to investigate. Once you trigger it, the
> debugger will indeed kick in, but all you need to do next is step
> through the code, so why do you care about switching to Emacs again?
Somehow, the problem manifests when I switch between frames (two frames
in the current repro) using C-` (bound to `other-frame').
But if I Alt-Tab to a different application and then Alt-Tab back to
Emacs, then the glyph is rendered fine - even if the "problematic" frame
gets selected.
> If you want to trigger this situation several times, and be able to
> activate and deactivate the breakpoint at will, I suggest the
> following technique:
>
> . put a breakpoint in some function that is easy to invoke
> interactively, but which otherwise is rarely called (my personal
> favorite is Frecenter, which you can then trigger with C-l)
> . put a breakpoint in ns_draw_window_cursor (or wherever you need),
> but make it disabled (the GDB command is "disable N" where N is
> the breakpoint number)
> . when you are ready to trigger the issue, type C-l, which will
> cause the debugger to kick in, and enable the breakpoint in
> ns_draw_window_cursor
> . continue Emacs, then trigger the ns_draw_window_cursor breakpoint
> and investigate
At this point the breakpoint will start hitting as soon as I switch to
an Emacs frame. I guess what would be ideal is a breakpoint which won't
hit until after I switch to another frame.
> . when you are done investigating and want to, say, set a breakpoint
> in some other place, do that, make the breakpoint disabled again
> and continue Emacs
> . when ready, type C-l again, enable the disabled breakpoint, and
> repeat the above procedure
>
> Another, or perhaps complementary, technique is to define conditions
> for breakpoints so that they trigger only when you want. For example,
> if you want a breakpoint to trigger only for a specific frame or
> window, find out the address of the corresponding struct window or
> struct frame (assuming there are variables of these types in the same
> scope as the breakpoint), then make the breakpoint conditioned on
> those variables having (or not having) those specific values. The
> usual method of finding out these addresses is the first time the
> breakpoint triggers. Then you can do:
>
> (gdb) print f
> $1 = (struct frame *) 0x1234567812345600
> (gdb) condition 3 f == 0x1234567812345600
>
> This makes breakpoint 3 trigger only when struct frame variable f has
> the value of this frame.
So step 1 find out the address of the second frame, step 2 switch to
first frame, step 3 enable a conditional breakpoint.
Thank you, I'll try experimenting with that.
next prev parent reply other threads:[~2024-07-10 2:46 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 3:14 bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization Dmitry Gutov
2024-07-01 11:36 ` Eli Zaretskii
2024-07-02 1:07 ` Dmitry Gutov
2024-07-06 8:56 ` Eli Zaretskii
2024-07-09 2:37 ` Dmitry Gutov
2024-07-09 11:31 ` Eli Zaretskii
2024-07-10 2:46 ` Dmitry Gutov [this message]
2024-07-10 11:58 ` Eli Zaretskii
2024-07-19 1:57 ` Dmitry Gutov
2024-07-20 8:30 ` Eli Zaretskii
2024-07-20 15:46 ` Dmitry Gutov
2024-07-20 16:03 ` Eli Zaretskii
2024-07-21 0:53 ` Dmitry Gutov
2024-07-21 7:20 ` Eli Zaretskii
2024-07-21 9:04 ` Eli Zaretskii
2024-07-21 23:22 ` Dmitry Gutov
2024-07-21 13:50 ` Dmitry Gutov
2024-07-21 14:55 ` Eli Zaretskii
2024-07-21 23:58 ` Dmitry Gutov
2024-07-22 14:45 ` Eli Zaretskii
2024-07-22 15:27 ` Alan Third
2024-07-22 16:02 ` Alan Third
2024-07-23 1:11 ` Dmitry Gutov
2024-07-23 11:19 ` Eli Zaretskii
2024-07-24 0:48 ` Dmitry Gutov
2024-07-24 11:32 ` Eli Zaretskii
2024-07-24 14:34 ` Dmitry Gutov
2024-07-24 16:29 ` Eli Zaretskii
2024-07-24 19:22 ` Dmitry Gutov
2024-07-24 20:08 ` Dmitry Gutov
2024-07-25 5:01 ` Eli Zaretskii
2024-07-25 16:14 ` Dmitry Gutov
2024-07-22 16:10 ` Eli Zaretskii
2024-07-22 19:02 ` Alan Third
2024-07-22 19:15 ` Eli Zaretskii
2024-07-22 19:47 ` Alan Third
2024-07-23 1:06 ` Dmitry Gutov
2024-07-23 11:17 ` Eli Zaretskii
2024-07-02 23:42 ` Stefan Kangas
2024-07-07 2:03 ` Dmitry Gutov
2024-07-09 18:22 ` Stefan Kangas
2024-07-10 2:56 ` Dmitry Gutov
2024-07-23 7:40 ` Gerd Möllmann
2024-07-24 0:56 ` Dmitry Gutov
2024-07-24 3:48 ` Gerd Möllmann
2024-07-24 19:16 ` Dmitry Gutov
2024-07-25 3:03 ` Gerd Möllmann
2024-07-25 5:39 ` Eli Zaretskii
2024-07-25 5:58 ` Gerd Möllmann
2024-07-25 14:46 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d67cdfa2-dc75-4d58-8f82-49ddc55f5e45@gutov.dev \
--to=dmitry@gutov.dev \
--cc=71866@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).