"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Mikhail <mp39590@gmail.com>
Subject:
Re: tog: status bar prompt about togglable events
To:
Mark Jamsek <mark@jamsek.com>
Cc:
gameoftrees@openbsd.org
Date:
Sat, 21 Jan 2023 11:21:56 +0300

Download raw body.

Thread
On Sat, Jan 21, 2023 at 07:00:24PM +1100, Mark Jamsek wrote:
> On 23-01-20 09:25PM, Mikhail wrote:
> > On Fri, Jan 20, 2023 at 09:09:07PM +0300, Mikhail wrote:
> > > Inlined patch adds short timed prompts to status bar about things like
> > > switching between diff algorithms, showing white spaces in patches,
> > > toggling bin/ascii views for blobs, changing committer and author
> > > representations, and switch between date/name sorting for ref view.
> > > 
> > > Originally I wanted it because I needed to see current diff algorithm,
> > > but decided to expand the patch to show all togglable events, except for
> > > ref view, where, for example, showing IDs speaks for itself by changing
> > > the look of the table and doesn't require a prompt.
> 
> I like the idea of this; however, where the information is currently
> echoed feels a little incongruous. And, perhaps more importantly,
> depending on the user's terminal width and current view, the information
> may not even be visible.
> 
> I'm also not sure about displaying some of these actions. You're right
> about the display of reference IDs being obvious. Likewise for toggling
> the reference's last modified date, and showing tree entry IDs too. The
> algorithm definitely makes sense as it's not easily, if at all,
> discernable.  Likewise for ignoring whitespace. However, toggling
> between author and committer can be surmised already; granted, you need
> to enter the diff view to make this distinction. Similarly, forcing
> ASCII text is also apparent from the diff; in a similar vein, the code
> doesn't report adjusting context lines as the diff speaks for itself.
> Lastly, the reference sort order is already evident, especially if the
> 'm' keymap is toggled but even if not, lexicographic order is obvious in
> most cases so it's simple to tell when sorted by name or by date.
> 
> That said, I really like the general idea, but it might be nice to see
> such action updates echoed to the bottom left of screen where we display
> prefixed count mod key input.  This way, it will always be visible
> irrespective of terminal width and view, which is important. It is also
> more consistent behaviour as this is where we already echo responses to
> user input, and, imo, won't feel out of place like it does appended to
> the end of the headline.
> 
> The below diff demonstrates this change in placement. The view struct
> char pointer 'prompt' is also renamed to 'action' as this seems more
> appropriate; prompt implies we're requesting input from the user, but
> the report describes action taken in response to user input. And
> the wording of some action reports has been changed to be more
> descriptive too.
> 
> There's also a related fix that should probably go in regardless of
> whether this action report lands: in view_loop() we initialise at
> a refresh rate of one tenth per second before reducing this to one
> second updates. However, the reduction was never hit due to a typo in
> the conditional. The following hunk fixes this:

I've tested the patch - it works and still solves original problem,
thanks!