From patchwork Sat Feb 22 11:33:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eli Zaretskii X-Patchwork-Id: 38275 Received: (qmail 11538 invoked by alias); 22 Feb 2020 11:33:59 -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 11520 invoked by uid 89); 22 Feb 2020 11:33:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.1 spammy=resize, height 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; Sat, 22 Feb 2020 11:33:58 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j5T2h-0004D6-7D; Sat, 22 Feb 2020 06:33:55 -0500 Received: from [176.228.60.248] (port=4109 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j5T2e-0004x3-RD; Sat, 22 Feb 2020 06:33:54 -0500 Date: Sat, 22 Feb 2020 13:33:44 +0200 Message-Id: <83mu9aj1pj.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: midenok@gmail.com, gdb@sourceware.org, gdb-patches@sourceware.org In-reply-to: <835zg5m7ib.fsf@gnu.org> (message from Eli Zaretskii on Mon, 17 Feb 2020 19:46:36 +0200) Subject: Re: GDB 9 TUI mode broken References: <835zg5m7ib.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes > Date: Mon, 17 Feb 2020 19:46:36 +0200 > From: Eli Zaretskii > CC: gdb@sourceware.org > > > From: Aleksey Midenkov > > Date: Mon, 17 Feb 2020 19:26:07 +0300 > > > > Now the window molders away after `winheight src +8` command. > > This looks like a bug, and is probably unrelated to colors. Suggest > to make a bug report. The patch below seems to fix some of the problem, but not all of it: the position of the status line (the one that shows the process information) is not updated correctly. Tom, where's the position update of the status line supposed to be handled? And btw, the meaning of the 'locator' object in tui_adjust_win_heights is unclear: to which window does it pertain, and what is the significance of this line: TUI_CMD_WIN->origin.y = locator->origin.y + 1; I think we could use some additional comments in tui-stack.c or tui-stack.h, to explain what is the meaning and expected use of tui_locator_window. --- gdb/tui/tui-win.c~0 2020-02-08 14:50:14.000000000 +0200 +++ gdb/tui/tui-win.c 2020-02-22 13:28:37.003625000 +0200 @@ -1077,20 +1077,25 @@ tui_adjust_win_heights (struct tui_win_i { struct tui_win_info *src_win_info; - primary_win_info->resize (new_height, width, - 0, primary_win_info->origin.y); if (primary_win_info->type == CMD_WIN) { win_info = *(tui_source_windows ().begin ()); src_win_info = win_info; + primary_win_info->resize (new_height, width, + 0, + primary_win_info->origin.y + diff); + win_info->resize (win_info->height + diff, width, + 0, win_info->origin.y); } else { win_info = tui_win_list[CMD_WIN]; src_win_info = primary_win_info; - } + primary_win_info->resize (new_height, width, + 0, primary_win_info->origin.y); win_info->resize (win_info->height + diff, width, - 0, win_info->origin.y); + 0, win_info->origin.y - diff); + } TUI_CMD_WIN->origin.y = locator->origin.y + 1; if ((src_win_info->type == SRC_WIN || src_win_info->type == DISASSEM_WIN))