From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 71866@debbugs.gnu.org
Subject: bug#71866: 30.0.50; [macOS] Cursor hiding char behind it with certain theme customization
Date: Tue, 09 Jul 2024 14:31:45 +0300 [thread overview]
Message-ID: <86sewiztr2.fsf@gnu.org> (raw)
In-Reply-To: <1f5f741f-d599-4051-8a34-27d349360eb8@gutov.dev> (message from Dmitry Gutov on Tue, 9 Jul 2024 05:37:10 +0300)
> 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?
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
. 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.
HTH
next prev parent reply other threads:[~2024-07-09 11:31 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 [this message]
2024-07-10 2:46 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sewiztr2.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71866@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.