On Fri, Sep 09, 2022 at 12:16:02AM +1000, Mark Jamsek wrote:
> On 22-09-03 04:05PM, Stefan Sperling wrote:
> > On Sat, Sep 03, 2022 at 11:46:14PM +1000, Mark Jamsek wrote:
> > > This is the same idea as the previous diff applied to the log view
> > > headline: extend the highlight colour to the full width of the line.
> > > 
> > > Admittedly subjective again, but I think it looks better in splitscreen
> > > when the log view is focussed.
> > 
> > Yes, this looks nicer.
> > 
> > The diff view should get the same change, I think. Perhaps other views, too?
> 
> Yes, I agree; this should be made consistent across all views. The below
> diff does this, plus one other related, albeit minor, change: make the
> tree view header like the blame view instead of the ref view. That is,
> move the line index to the path line.
> 
> For example, before this diff:
> 
> ----8<-----------------------------------------------------------------
> commit 2bd4b7e472a90a7907e78f8b45a7b30fe2d10b97 [1/19]
> /
> 
>   .gitignore
>   CHANGES
>   ...
> ----------------------------------------------------------------->8----
> 
> After this diff:
> 
> ----8<-----------------------------------------------------------------
> commit 2bd4b7e472a90a7907e78f8b45a7b30fe2d10b97
> [1/19] /
> 
>   .gitignore
>   CHANGES
>   ...
> ----------------------------------------------------------------->8----
> 
> I did this because, imo, the tree view header is more like the blame
> view's than the ref view's in that it contains a commit ID, line index,
> and path. Plus, in narrow terminals, there's a greater chance the
> "commit ID" string will consume COLUMNS such that (part of) the index is
> off-screen; whereas, "references" in the ref view is much shorter so the
> index is more likely to remain visible. But I'm happy to remove this bit
> of the diff if anyone disagrees.

I like this a lot. Thanks! ok stsp@

A seperate but related cosmetic problem I noticed during testing,
at least in my terminal, is that the new highlighting style looks
exactly like a view's selection cursor. This can be confusing.

For example, in a horizontal-split screen after: tog; S R j j j j
my screen appears like what I have pasted below between "[[[" and "]]]".

There are 3 lines which are highlighted, all in the same way.
I have marked these lines with an asterisk in the first column:

[[[
commit f0f62654dd608d01879094d1f491287f0f7029f1 [1/27] main, origin/main
* 2022-09-08 mark  tog: extend log view author highlight colour to full field widt
2022-09-07 stsp  Xr httpd.conf
2022-09-07 stsp  document gotwebd command line options
2022-09-07 stsp  fix documentation of gotwebd.conf default path
2022-09-07 stsp  bump version number
2022-09-07 stsp  CHANGES for 0.75
--------------------------------------------------------------------------------
* references [5/236]
HEAD -> refs/heads/main
refs/heads/delta-cache
refs/heads/main
refs/heads/merge-graph
* refs/heads/ohash
refs/heads/patch-paths-differ
]]]

The refs view has focus indication (second asterisk) and an active
cursor I can move (third asterisk). That is fine.

The first asterisk shows a highlighted line in the log view; this is
the log view's selection cursor position. This cursor cannot be moved
since the log view is out of focus. But the cursor still stands out
visually just in the same way as the other highlighted lines, and this
could easily confuse my idea about input focus.

What do you think about not highlighting a cursor when its view is not
in focus? I believe that would give a better visual impression.