While working on the previous patches I noticed that in some cases I
was seeing two calls to tui_source_window_base::refresh_window when
scrolling the window horizontally.
The two calls would trigger in for the tui-disasm-long-lines.exp test
when the pad needed to be refilled. The two called both come from
tui_source_window_base::show_source_content. The first call is nested
within check_and_display_highlight_if_needed, while the second call is
done directly at the end of show_source_content.
The check_and_display_highlight_if_needed is being used to draw the
window box to the window, this is needed here because
show_source_content is what gets called when the window needs
updating, e.g. after a resize. We could potentially do the boxing in
refresh_window, but then we'd be doing it each time we scroll, even
though the box doesn't need changing in this case.
However, we can move the check_and_display_highlight_if_needed to be
the last thing done in show_source_content, this means that we can
rely on the refresh_window call within it to be our single refresh
call.
There should be no user visible changes after this commit.
{
gdb_assert (!m_content.empty ());
- check_and_display_highlight_if_needed ();
-
/* The pad should be at least as wide as the window, but ideally, as wide
as the content, however, for some very wide content this might not be
possible. */
for (int lineno = 0; lineno < m_content.size (); lineno++)
show_source_line (lineno);
- refresh_window ();
+ /* Calling check_and_display_highlight_if_needed will call refresh_window
+ (so long as the current window can be boxed), which will ensure that
+ the newly loaded window content is copied to the screen. */
+ gdb_assert (can_box ());
+ check_and_display_highlight_if_needed ();
}
tui_source_window_base::tui_source_window_base ()