activebordercolor defines background of INactive border labels

[matejcik]

Describe the bug

this happens with mate-terminal

TERM=xterm-256color
COLORTERM=truecolor

To Reproduce
i'm using the following config:

 confirmonquit: false
 git:
   autofetch: false
   merging:
     manualcommit: false
   skiphookprefix: WIP
 gui:
   commitlength:
     show: true
   mouseevents: false
   scrollheight: 2
   scrollpastbottom: true
   theme:
     activebordercolor:
     - yellow
     lighttheme: true
 reporting: "off"
 startuppopupversion: 1
 update:
   days: 14
   method: prompt

[jesseduffield]

Not sure how best to tackle this one. here's what I see:

I want 'Local Branches' to be distinguished from the other tabs of the same panel so that we know what's being shown, but I don't want the user to think that's the currently active tab. I've got bold being applied additionally when it is the active tab.

[jesseduffield]

I've thought about this some more and given that the bold attribute isn't obvious in various terminals, I'm happy to just leave the tabs of un-focused panels uncoloured. I'll chuck a good-first-issue label on this.

I'm pretty sure the place to change is the drawTitle function in vendor/github.com/jesseduffield/gocui/gui.go. The guide to updating gocui in the contributing guide will prove helpful https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#updating-gocui

[curllog]

@jesseduffield Hi is this issue still valid? can you help me in details please, this will be my first commit for lazygit

[jesseduffield]

@curllog sorry for the late reply. I've actually changed my mind on this: I think we should highlight the selected tab on unfocused views because you already know whether a view is focused based on whether the border is highlighted. If we don't highlight the selected tab on unfocused views, we can't know which tab's content is being rendered, which can cause confusion. Even if we use the bold attribute on the selected tab, it's still not clear. For example:

So I'm going to remove the good-first-label until we decide on a better approach, and if we can't think of one, then I'll close the issue