From: Mikhail Subject: Re: tog: status bar prompt about togglable events To: Mark Jamsek Cc: gameoftrees@openbsd.org Date: Sat, 21 Jan 2023 11:21:56 +0300 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!