Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Make "list" work again in TUI
Date: Wed, 12 Sep 2018 12:20:00 -0000	[thread overview]
Message-ID: <66752a61-08f1-5588-691d-205e89b09471@redhat.com> (raw)
In-Reply-To: <87musq4jdk.fsf@tromey.com>

On 09/09/2018 07:26 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
> 
> Tom> This patch makes the "list" command work again by adding some caching.
> Tom> Now the TUI tracks the previously displayed frame, PC, and inferior;
> Tom> and only updates the display if one of these was changed by the
> Tom> previous command.
> 
> I have a question about this one now.
> 
> In the bug the original poster said that to get back to the current
> location, he would use the "frame" command.  This doesn't work with my
> patch, and I'm not sure how it would have worked in the past.

I used to do that too.

> 
> One part of how the TUI links to the CLI is very convoluted -- there is
> a special case in tui-out to notice how the "list" command emits fields
> and newlines and to use that to refresh the window.  I'd rather not do
> anything this roundabout and fragile...

Yeah.

> 
> Other parts of the CLI use #ifdef TUI to decide what action to take when
> the TUI is available.  This seems like an "old school" approach though I
> must say I prefer its directness.  I wouldn't mind rewriting "list" to
> do this.
> 
> Another option might be to have the frame command unconditionally notify
> some observer.  Then the TUI could listen for this.
> 
> Anyway, I'd appreciate comments on which approach CLI/TUI integration
> ought to ideally take.  I don't know the history here and there aren't
> guiding comments that I could find.

I'm under the impression that the TUI was added along with the
major HP dump/merge back in the day, meaning original design history
is probably lost.  I may be wrong.

Offhand, it seems to me that the TUI should update its listed source
whenever the CLI's current source changes.  I.e., the TUI's source
window should be updated whenever set_current_source_symtab_and_line is
used to update the current source & line for the CLI's "list".  Which
suggests that for "frame" TUI re-centering, an observer notification from
within set_current_source_symtab_and_line would work.

If we always updated the source window from a TUI observer for
that notification, could we make tui_refresh_frame_and_register_information
just never update the source window?  I.e., remove the select_source_symtab
call from tui_refresh_frame_and_register_information or something along
those lines.  That assumes that if the frame changed, then presumably,
set_current_source_symtab_and_line will have already been called, which
it seems is true.  (if it isn't, then "list" won't be updated either, and
we're back to the argument about keeping "list" and the TUI in sync.).
That would eliminate the need for the caching.

Thanks,
Pedro Alves


  reply	other threads:[~2018-09-12 12:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-08 14:32 Tom Tromey
2018-09-09 18:26 ` Tom Tromey
2018-09-12 12:20   ` Pedro Alves [this message]
2018-09-12 12:31     ` Pedro Alves
2018-09-15 21:12       ` Tom Tromey
2018-09-15 22:21         ` 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=66752a61-08f1-5588-691d-205e89b09471@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --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