gdb-ui and hl-line-mode

gdb-ui and hl-line-mode

[Eli Zaretskii]

Some people, when they debug a program, like to have the current line
in the source window to be clearly visible.  One way to do that in
Emacs is to turn on the hl-line-mode in the source buffer, but the
results are strange: if you step through the code when the source
window is the currently selected one, the highlighted line stays one
step behind the fringe arrow and the cursor (e.g., the arrow points to
line 10, whereas line 9 is highlighted); switching to another window
and back fixes the overlay position.  And if you step with the source
window is not the selected one (e.g., you type `next' commands into
the GUD buffer), the highlight overlay does not move at all; however,
if you switch to the source window, the highlight overlay is correctly
moved to the current source line.

Is this some snafu with post-command hook being run a tad too early?

gdb-ui and hl-line-mode

[Nick Roberts]

Eli Zaretskii writes:
 > Some people, when they debug a program, like to have the current line
 > in the source window to be clearly visible.  One way to do that in
 > Emacs is to turn on the hl-line-mode in the source buffer, but the
 > results are strange: if you step through the code when the source
 > window is the currently selected one, the highlighted line stays one
 > step behind the fringe arrow and the cursor (e.g., the arrow points to
 > line 10, whereas line 9 is highlighted); switching to another window
 > and back fixes the overlay position. 

Is this due to the fact GDB runs asynchronously i.e gud-call finishes
before the output of GDB is collected through gud-filter?

 >                                     And if you step with the source
 > window is not the selected one (e.g., you type `next' commands into
 > the GUD buffer), the highlight overlay does not move at all; however,
 > if you switch to the source window, the highlight overlay is correctly
 > moved to the current source line.

The commentary says:

;; Caveat: the buffer's point might be different from the point of a
;; non-selected window.

which presumably has something to do with point and window-point having
different values.

Nick