From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79487 invoked by alias); 14 Mar 2019 20:25:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 79474 invoked by uid 89); 14 Mar 2019 20:25:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=horizontal, portion, video, 50.000000000 X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Mar 2019 20:25:28 +0000 Received: by mail-wr1-f66.google.com with SMTP id d17so7267236wre.10 for ; Thu, 14 Mar 2019 13:25:28 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id x17sm46526338wrd.95.2019.03.14.13.25.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 13:25:26 -0700 (PDT) Subject: "next" into line longer than the source window-width (Re: [RFC 8.3 0/3] Some style fixes) To: Eli Zaretskii , Hannes Domani , Tom Tromey References: <20190308210433.32683-1-tromey@adacore.com> <1828778750.3318305.1552141698307@mail.yahoo.com> <87o96g3upj.fsf@tromey.com> <375483967.6114402.1552410513314@mail.yahoo.com> <83lg1i3hkj.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <6035325c-bb76-fe7f-5688-8c78a8b89a1a@redhat.com> Date: Thu, 14 Mar 2019 20:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <83lg1i3hkj.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00302.txt.bz2 On 03/13/2019 03:44 PM, Eli Zaretskii wrote: > I also found another regression in the TUI configuration: if you step > with, say, "next" through the program, and execution winds up on a > line that is longer than the source window-width, then the current > line gets redrawn in reverse video, and as result it overwrites the > window-frame and a portion of the next source line. This happens > because we only update one source line, and we do that in a way that > doesn't take the window width and horizontal scrolling offset into > account. > > Here's the patch that fixes this regression: > > --- gdb/tui/tui-winsource.c~5 2019-03-12 16:51:50.000000000 +0200 > +++ gdb/tui/tui-winsource.c 2019-03-13 08:21:02.303443600 +0200 > @@ -382,12 +387,30 @@ tui_set_is_exec_point_at (struct tui_lin > { > changed++; > content[i]->which_element.source.is_exec_point = new_state; > - tui_show_source_line (win_info, i + 1); > } > i++; > } > if (changed) > - tui_refresh_win (&win_info->generic); > + { > + struct gdbarch *gdbarch = win_info->detail.source_info.gdbarch; > + struct symtab *s = NULL; > + > + if (win_info->generic.type == SRC_WIN) > + { > + struct symtab_and_line cursal > + = get_current_source_symtab_and_line (); > + > + if (cursal.symtab == NULL) > + s = find_pc_line_symtab (get_frame_pc (get_selected_frame (NULL))); > + else > + s = cursal.symtab; > + } > + tui_update_source_window_as_is (win_info, gdbarch, s, > + win_info->generic.content[0] > + ->which_element.source.line_or_addr, > + FALSE); > + tui_refresh_win (&win_info->generic); > + } The substance of the patch LGTM. But all this code above looks very much like the new tui_refill_source_window function, added today by 6f11e6824e15. I think you can replace all the above with: - tui_refresh_win (&win_info->generic); + tui_refill_source_window (win_info); Thanks, Pedro Alves