On Fri, Sep 16, 2022 at 12:44:28AM +1000, Mark Jamsek wrote:
> On 22-09-15 03:35PM, Stefan Sperling wrote:
> > Because the help view is implemented as a normal view, tog's parent/child
> > view behaviour determines where a new help view appears. For example,
> > when in horizontal split mode, the help view appears either full-screen
> > or in a split-screen, depending on which view has focus when the help view
> > is opened. I would expect help text to always appear in the same frame as
> > the view which is being documented. This would likely require some further
> > refactoring of the way new views are opened?
> 
> Yes, we'll need to tweak the new view code a bit, but I don't think this
> will be difficult.
> 
> That said, this is the only thing I'm a little unsure about tbh. The
> original implementation did something like this: a pad popped up,
> partially obscuring the current view, but no other views could be
> accessed until the help pad was closed. One of the secondary reasons
> I dropped this approach was because I thought it would be useful to have
> the help reference visible while browsing the primary view. But the
> current implementation doesn't fully cater to this either because, as
> you allude to, it adheres to the current view rules such that the help
> view only opens as a child view if opened from a parent, but when opened
> from a child, it becomes a parent and blocks all previous views.
> 
> I'll cook a diff implementing your suggested change and shoot it through
> so we can get a feel for what we prefer. As I typed this and thought
> about it more, I think this makes the most sense anyway. Thanks, Stefan!

Hmm, you may be right that seeting the help view in a separate screen
from the view it is documenting would be useful. That would mean the help
view would have to "take over" the "other" view in situations where the
screen is already split, and "restore" the "other" view when the help
view quits? I don't think our current view management code can support
this. It treats all views as equally important, and then we also need
to take into account terminals which are too small to display two views
at the same time...

The more "window management" code we have in tog, the harder it will
be to maintain this program. So perhaps it would be better to always
take over the active view, for now? Most TUI programs I've used work
like that, letting their online help screens obscure the current display.

We could think about displaying the help view and the view it is documenting
in parallel later. I expect it won't be trivial to get consistent behaviour
in all cases, even if it may seem like an easy problem on the surface.

An already supported way of viewing both a tog view and usage information
on the same screen is to open tog in one terminal window (or tmux pane)
and read the tog man page in another window ;)