From patchwork Tue Mar 12 16:44:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eli Zaretskii X-Patchwork-Id: 31824 Received: (qmail 102486 invoked by alias); 12 Mar 2019 16:44:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 102475 invoked by uid 89); 12 Mar 2019 16:44:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=displays, falls, scrolling, HX-Languages-Length:4262 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Mar 2019 16:44:56 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3kWM-0003r4-Kr; Tue, 12 Mar 2019 12:44:54 -0400 Received: from [176.228.60.248] (port=4068 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h3kWL-00033d-Ue; Tue, 12 Mar 2019 12:44:54 -0400 Date: Tue, 12 Mar 2019 18:44:47 +0200 Message-Id: <8336ns3uv4.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <874l899nh3.fsf@tromey.com> (message from Tom Tromey on Mon, 11 Mar 2019 14:15:36 -0600) Subject: Re: [RFC 8.3 0/3] Some style fixes References: <20190308210433.32683-1-tromey@adacore.com> <83pnr08tc8.fsf@gnu.org> <83zhq26fcw.fsf@gnu.org> <874l899nh3.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes > From: Tom Tromey > Cc: tromey@adacore.com, gdb-patches@sourceware.org > Date: Mon, 11 Mar 2019 14:15:36 -0600 > > Eli> However, the artifacts I saw in the TUI display in the > Eli> pretest are still there. In particular, the right-hand side of the > Eli> frame of the source window still gets overwritten when stepping > Eli> through the inferior's code, and it looks like the newline is not > Eli> echoed after commands typed in the command window. > > I wonder if this is the "nonl" bug. > You can test that theory by applying the appended. It fixes the problems in the command window, so I think we should apply this if no better ideas are brought up. But the problems in the source window are not solved by this patch, they have other reasons. I debugged almost all of the problems I'm aware of, please see the annotated patches below. If they look reasonable, I will push them. After these patches, I have only one more problem: horizontal scrolling of the source window. First, the first press of left-arrow doesn't have any effect; and second, scrolling draws TAB characters incorrectly, it treats each TAB as if it took a single column on the screen, so text after a TAB jumps by 8 columns when you scroll instead of moving by one column. I hope to have solution for this tomorrow. Here are the patches for the other problems: 1. The first patch fixes the problem noticed by Pedro: pressing DOWN arrow in the command window doesn't scroll the source window. This is because we don't initialize the s->nlines field, and then tui_vertical_source_scroll thinks we are off the chart. This fixes that: --- gdb/source-cache.c~4 2019-03-10 08:34:47.422752400 +0200 +++ gdb/source-cache.c 2019-03-12 11:50:15.094147600 +0200 @@ -194,6 +194,12 @@ source_cache::get_source_lines (struct s std::ifstream input (fullname); if (input.is_open ()) { + if (s->line_charpos == 0) + { + scoped_fd desc = open_source_file (s); + if (desc.get () >= 0) + find_source_lines (s, desc.get ()); + } srchilite::SourceHighlight highlighter ("esc.outlang"); highlighter.setStyleFile("esc.style"); 2. The fix for avoiding to overwrite the source window frame is simple: revert 4a3045920. I don't really understand why that change was made: AFAIU, wclrtoeol clears to the end of the window line, and cannot be told to clear only part of the line. --- gdb/tui/tui-winsource.c~4 2019-02-27 06:51:50.000000000 +0200 +++ gdb/tui/tui-winsource.c 2019-03-12 10:57:02.052875200 +0200 @@ -285,7 +285,12 @@ tui_show_source_line (struct tui_win_inf wattroff (win_info->generic.handle, A_STANDOUT); /* Clear to end of line but stop before the border. */ - wclrtoeol (win_info->generic.handle); + int x = getcurx (win_info->generic.handle); + while (x + 1 < win_info->generic.width) + { + waddch (win_info->generic.handle, ' '); + x = getcurx (win_info->generic.handle); + } } void 3. This patch fixes another problem noticed by Pedro: the first time you type UP or DOWN arrow in the command window, GDB should scroll the source window, but instead it displays the line number and the file name in the command window(?). What happens there is that the first time we call tui_ui_out::do_field_int, it doesn't initialize m_line, because m_start_of_line is -1, as set by the constructor; and then the following call to tui_ui_out::do_field_string falls back to cli_ui_out::do_field_string because m_line is zero. The fix below is perhaps somewhat ad-hoc, mainly because I couldn't understand the semantics of the values of m_start_of_line, especially its non-positive values; please consider documenting them in the header. Maybe if someone explains the semantics, I could come up with a more sound patch (or conclude that the below is TRT). Also, it looks like the second test for m_line > 0 in tui_ui_out::do_field_string is redundant? --- gdb/tui/tui-out.c~4 2019-02-27 06:51:50.000000000 +0200 +++ gdb/tui/tui-out.c 2019-03-12 12:30:23.924230000 +0200 @@ -34,6 +34,9 @@ tui_ui_out::do_field_int (int fldno, int if (suppress_output ()) return; + if (m_start_of_line < 0 && m_line == 0) + m_start_of_line = 0; + /* Don't print line number, keep it for later. */ if (m_start_of_line == 0 && strcmp (fldname, "line") == 0) {