bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27647: 26.0.50; Line numbers implemented natively disappear momentar


From: Noam Postavsky
Subject: bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus
Date: Thu, 09 Nov 2017 19:38:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Thanks for spending time to debug this and come up with that crucial
> fix. Did any of the within-emacs debug tactics help you figure this
> out? Or was it putting breakpoints and catching them in gdb? Or did
> you go the final hard way, and review the code manually?

So glad you asked, now I can relive the glory of the hunt :D

The first thing I tried was the 'watch Vdisplay_line_numbers', but this
gave me no hits except for some spurious stuff related to buffer-local
variables; after changing to (setq-default display-line-numbers t) I got
no hits at all.  So it was fairly clear that the problem lay below the
lisp level.

Then I considered putting a breakpoint into the display code, which is a
bit tricky because I needed to drag the mouse to trigger the problem,
but if a breakpoint is hit before that Emacs is frozen and can't
register the mouse drag.  I tried to reduce the recipe to some lisp code
to be evaluated based on mouse-drag-and-drop-region, but I didn't
manage to come up with something that worked.

Then I looked a bit through the display code to figure if a breakpoint
conditioned on mouse dragging could work, and I noticed the
should_produce_line_number function, so I just put a breakpoint on every
place which returned false.  Bang, success!

Except I then had to check the values of WINDOW_FRAME (it->w) to make
sure I hadn't actually hit the case where the code *correctly* skips
line numbers for tooltips.  A quick grep for tip_frame soon turned up
x_hide_tooltip which had the comment that explained what was going on.

> Also thanks to everyone who helped figure out a recipe, which is
> equally important :). 

Most definitely, I could not have done anything without a simple way to
reproduce the problem.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]