[FEATURE] Option to custom/remove the last `resetStyles` for using outside of tmux

[hieulw]

Is your feature request related to a problem? Please describe. This sounds a bit odd but I'm using gitmux to display git status in wezterm status bar because I found no git status snippets for wezterm in internet. I used to use gitmux with tmux for a long time, now I want to use wezterm instead and migrate gradually to it. Everything seems ok but the last resetStyles there's no way of removing it in config file right now. https://github.com/arl/gitmux/blob/main/tmux/formater.go#L213

Describe the solution you'd like have an Option to whether show or not the last resetStyles.

Describe alternatives you've considered Wezterm's config is using lua so I can just use git in sub process and get the git status values but I think gitmux would be lots more performance also the fact that it almost out-of-the-box option.

Additional context

# gitmux.conf
tmux:
  styles:
    clear: ""
    state: "\e[31;1m"
    branch: "\e[37;1m"
    remote: "\e[36m"
    divergence: "\e[33m"
    staged: "\e[32;1m"
    conflict: "\e[31;1m"
    modified: "\e[31;1m"
    untracked: "\e[35;1m"
    stashed: "\e[36;1m"
    insertions: "\e[32m"
    deletions: "\e[31m"
    clean: "\e[32;1m"
    reset: "\e[0m"

[arl]

Hi We could make the resetStyles string configurable, and let the current value as the default, so you could let it empty. Would that fix your issue?

[hieulw]

Hi We could make the resetStyles string configurable, and let the current value as the default, so you could let it empty. Would that fix your issue?

Yes, that would be great to have ! Thank you !

[arl]

By the way I love that you're using gitmux in a way that wasn't intended to. That's actual hacking 💻 ❤️

[hieulw]

By the way I love that you're using gitmux in a way that wasn't intended to. That's actual hacking 💻 ❤️

Yeah! It always feels good when you can utilize existing tools without doing much work, thanks to single-responsibility tools like this and their composable nature. 😄

[arl]

I see that the resetStyles constant resets background and foreground tmux styles to default, which is the same as setting the #none style, per tmux documentation. We already use #none as the default value for the clear gitmux style token.

So I think we could simply remove the resetStyles constant, replacing it with a final gitmux clear style.

As far as I can tell, that would achieve the same for gitmux default config. And that would solve @hieulw 's use case, since for them, clear is already set to the empty string.

Anybody has thoughts on that? More precisely, what are you all using as value for clear in your configuration?

[hieulw]

I think people would leave clear as default or doesn't really care at all about clear customization. Search people's config: https://github.com/search?q=gitmux+clear&type=code&p=1 As you can see, most people will leave it as #[none] or #[fg=none].

PS: Oh, I found a case which people could custom clear style that is changing the background, bold style.

  styles:
    clear: "#[bg=color232,fg=default,bold]"

[arl]

Thanks for the search, very useful.

PS: Oh, I found a case which people could custom clear style that is changing the background, bold style.

Even in that case, they could still append a #[none] to layout if they wish to reset tmux styles and hence have the same behaviour as now. Or it could also be added directly in their tmux status string definition. If I remember correctly resetStyles was added to satisfy some user that had specific styles after gitmux string.

In any case I think we're good with current proposition.

[hieulw]

Thank you. I'm looking forward the next release !

Right now, I'm living with this 😄
I'm not comfortable with Go to create a PR yet.

[hieulw]

Even in that case, they could still append a #[none] to layout if they wish to reset tmux styles and hence have the same behaviour as now.

Based on this, I found myself make it works. Thanks!

  layout:
    - flags
    - stats
    - branch
    - remote
    - "\r" 

Everything looks clean now.

[arl]

Oh cool. In this case, should we close the issue?