From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, Hannes Domani <ssbssa@yahoo.de>
Subject: Re: [PATCH 0/6] Vertical scrolling and another small bug fix
Date: Thu, 09 Jan 2020 23:28:00 -0000 [thread overview]
Message-ID: <20200109232852.GZ3865@embecosm.com> (raw)
In-Reply-To: <874kx7f453.fsf@tromey.com>
* Tom Tromey <tom@tromey.com> [2020-01-07 12:38:48 -0700]:
> Andrew> This is a different (simpler) approach than I originally suggested.
>
> I meant to reply to that one. I thought the changes in tui-hooks.c
> looked reasonable. If you want to resurrect that, I'm in favor of
> it.
The reason I abandoned the old approach was that it moved the
redisplay from the pre-prompt hook into the symtab-changed hook. This
has two problems:
First, calling 'tui_add_win_to_layout (SRC_WIN);' in the symtab
changed hook is not OK, consider stopping after a 'continue' command,
the symtab will change, but we don't want the SRC window to reappear.
So, we should only redisplay SRC if the symtab changes AND the current
frame doesn't change. The pre-prompt hook achieves this due to its
ordering of the checks.
Second, even if we could solve the above problem, there are cases
where the current symtab changes multiple times due to a single
command (I forget what, but I was probably testing with list at the
time). If we redraw the contents of the SRC window on every symtab
changes event this is a bit wasteful - though probably not critical.
I've been playing with the idea of having the TUI maintain its own
idea of current source location. When the global symtab change event
fires we'd copy the global location into the TUI location, but, when
the TUI scrolls we'd update the TUI only location. Both the SRC and
ASM windows would draw their contents based on the TUI's location
value.
Anyway, I made a little progress, but still don't have it working, so
I don't know if there's a reason why is wouldn't work...
Thanks,
Andrew
>
> Andrew> I'm still not really happy with how the tui keeps track and displays
> Andrew> the current symtab_and_line
>
> Me too.
>
> Andrew> However, I think leaving the ability to vertically scroll broken isn't
> Andrew> good, and I think this series is a step in the right direction
> Andrew> (maybe?).
>
> Agreed. It all looks good to me.
>
> Tom
next prev parent reply other threads:[~2020-01-09 23:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191221153325.6961-1-ssbssa.ref@yahoo.de>
2019-12-21 15:34 ` [RFC][PATCH] Call tui_before_prompt in do_scroll_vertical Hannes Domani via gdb-patches
2019-12-22 0:58 ` Andrew Burgess
2019-12-22 1:25 ` Hannes Domani via gdb-patches
2019-12-23 0:03 ` Tom Tromey
2019-12-23 0:19 ` Hannes Domani via gdb-patches
2019-12-23 1:23 ` Andrew Burgess
2020-01-07 11:52 ` [PATCH 2/6] gdb/testsuite/tui: Split enter_tui into two procs Andrew Burgess
2020-01-07 19:19 ` Tom Tromey
2020-01-07 11:52 ` [PATCH 5/6] gdb: Fix scrolling in TUI Andrew Burgess
2020-01-07 19:36 ` Tom Tromey
2020-01-07 11:52 ` [PATCH 4/6] gdb/tui: Fix 'layout asm' before the inferior has started Andrew Burgess
2020-01-07 19:31 ` Tom Tromey
2020-01-07 11:52 ` [PATCH 6/6] gdb/tui: Link source and assembler scrolling .... again Andrew Burgess
2020-01-07 19:37 ` Tom Tromey
2020-01-07 11:52 ` [PATCH 3/6] gdb/testsuite/tui: Introduce check_box_contents Andrew Burgess
2020-01-07 19:30 ` Tom Tromey
2020-01-07 11:52 ` [PATCH 0/6] Vertical scrolling and another small bug fix Andrew Burgess
2020-01-07 19:38 ` Tom Tromey
2020-01-09 23:28 ` Andrew Burgess [this message]
2020-01-07 11:52 ` [PATCH 1/6] gdb/testsuite/tui: Always dump_screen when asked Andrew Burgess
2020-01-07 18:54 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200109232852.GZ3865@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=ssbssa@yahoo.de \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox