arl / gitmux

:computer: Git in your tmux status bar

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Local Branch text does not take formatting

Science4583 opened this issue · comments

Expected Behavior

Setting Branch style should affect branch text

Actual Behavior

Only affects symbol

image

Steps to Reproduce the Problem

tmux:
  symbols:
    branch: ' '
    hashprefix: ':'
    ahead: ↑·
    behind: ↓·
    staged: ' '
    conflict: ' '
    modified: '➕ '
    untracked: '… '
    stashed: ' '
    clean: 
  styles:
    state: '#[fg=red]'
    branch: '#[fg=white]'
    remote: '#[fg=cyan]'
    staged: '#[fg=green]'
    conflict: '#[fg=red]'
    modified: '#[fg=red]'
    untracked: '#[fg=magenta,bold]'
    stashed: '#[fg=cyan,bold]'
    clean: '#[fg=green,bold]'
  layout: [' ', branch, .., remote-branch, divergence, ' - ', flags, ' |']
  options:
    branch_max_len: 0

Specifications

  • OS: Fedora 30
  • gitmux version: 0.7.0
  • tmux version: 2.9a

Thanks @mbazdell for the report.
I'm going to look into that soon.

Just a quick question (I'm not asking to look into it, it's just in case you know the answer):
Did you always notice this behavior or has it been happening since a specific version of gitmux?
Thank you

Just tested back to 0.4.0 and it seems to include a #[default] right before the branch name.

#[fg=default]#[fg=white] #[fg=default]master..#[fg=default]#[fg=cyan]origin/master#[fg=default] - #[fg=default]#[fg=green,bold]✓

I noticed in my .tmux.conf that I hadn't specified set -g status-fg to anything. Setting that changed the colors on the text marked for #[default] and resolved my issue.

Perhaps a feature request? Might be simple enough solution to just move where the #[default] is being set. My current Layout line looks like

layout: [' ', branch, '#[fg=blue]..', remote-branch, divergence, '#[fg=blue] - ', flags, '#[fg=blue] |']

I see. You're right the format string should be consistent and do not depend on whether the user had set a status foreground status-fg.
Thanks again for reporting.
I'll look into that

@mbazdell this is fixed in latest master.
You can find this fix (and others) in the latest release.