More compact diplay

[jderusse]

First of all, thank you for this script.. I really love it !

But, I miss some feature like:

• displaying the number of changes
• having a smaller bar
• hidde=ing unnecessary informations (ie, displaying the remote name only when you have to push or merge)

So, I forked your repositopry (https://github.com/jeremy-derusse/oh-my-git) and made few changes. But, this changes are personal and break BC (replace has_XXXX by number_of_XXXX in bash will break custom themes), That why, i'll not create a pull request (shame on me :disappointed:)

But, if you're interested by my changes we could find a way to do it.

Here is a screen shot for my very-custom theme

[arialdomartini]

It is amazing!

I love that it uses a completely different approach than mine. The idea behind the original oh-my-git is to have a dashboard, something like the instrumental panel in a car, where all the lights and the symbols are always at the same exact position, and they turn on and turn off, depending on events. With this approach my eyes won't have to look for a message; they can learn where certain kind of messages are, and this hopefully relieves the burden of understanding the prompt. That's why I thought that showing the number of files would be a bit too much.

Anyway, I can easily understand that it is a matter of taste. And I see that your version is gorgeous!

That's why I wonder how could we include your theme in the repo (assuming that you don't mind). For zsh it would be easy, since there's a file for each theme, and the user can select the desired theme with antigen theme arialdomartini/oh-my-git-themes whatever.

What could we do for bash? Different branches? A variable? Any idea?

[jderusse]

What about include a different file in bashrc: source /home/jderusse/oh-my-git/prompt-theme-a.sh

[arialdomartini]

Yeah! This is what I was thinking driving the car back home after work today.

Actually, oh-my-git is comprised of two elements: base.sh, which contains the function build_prompt, and prompt.sh which contains the function custom_build_prompt.

The first one analyses the environment and pass the second one a set of variables and flags, telling it "this is a repo, we are on branch master" and so on.

Since base.sh contains the common code for all the themes (both for bash and zsh), I think a theme should not repeat that code, but either reference it as a dependency or be called by it.

A "theme" is actually a specific implementation of custom_build_prompt.

Hence, I think we have at least 2 roads:

1. include in .bashrc either source ~/.oh-my-git/theme-x.sh for the theme x or source ~/.oh-my-git/theme-y.sh for the theme y, where each theme must include source base.sh
2. or we could include just source ~/.oh-my-git/prompt.sh and then use a variable like omg_theme=jderusse and have the switch case inside prompt.sh which will perform the `source`` of the right theme

The solution 1 is straightforward to implement. The 2 is seems a bit more user friendly to me.

Please, consider I must be compatible with zsh as well.

What's your opinion?

[arialdomartini]

@jeremy-derusse I meant to say, in order to include your theme, we'd need to patch base.sh file, so that it returns the new variables that you calculate (the number of untracked files and so on). Those variables will be passed to all the themes, so I think I'll need to modify them. I'd like to know your point of view, before starting this. Chances are you have a different strategy to propose.

[jderusse]

I prefere the solution 1, because it simple to wrote and did not use a global variable, but that's just my 2 cents opinion :)

Half agree with your second comment.

• Aggree, that that should keep has_xxxx to keep backward compatibility.
• but this metod is called with 24 arguments, I'm not sure that adding 7 new arguments (and maybe more with futur evolutions) is a good thinks.

Do you think it could be possible to use base.js has a toolset and inverse the calls: Actually we have:

prompt.js: bash_prompt()
 => base.js: build_prompt()
     =>  prompt.js: custom_build_prompt()

my proposal (I keep the existing names for more understandably, but file and methods should be renamed)

promp.js: bash_prompt()
 => promp.js: custom_build_prompt()
     => base.js: get_current_action()
     => base.js: get_git_statuses()
     => base.js: get_git_branches()

and this is an example for one of this method.

function get_git_statuses () {
    local git_status="$(git status --porcelain 2> /dev/null)"
    local action="$(get_current_action)"

    local number_of_untracked_modifications=$($grep -c "^.M " <<< "$git_status")
    local number_of_untracked_deletions=$($grep -c "^.D " <<< "$git_status")
    local number_of_untracked_adds=$($grep -c "^?? " <<< "$git_status")
    local number_of_untracked_changes=$(($number_of_untracked_modifications + $number_of_untracked_deletions + $number_of_untracked_adds))

    local number_of_cached_modifications=$($grep -c "^M " <<< "$git_status")
    local number_of_cached_adds=$($grep -c "^A " <<< "$git_status")
    local number_of_cached_deletions=$($grep -c "^D " <<< "$git_status")
    local number_of_cached_changes=$(($number_of_cached_modifications + $number_of_cached_adds + $number_of_cached_deletions))

    echo "$number_of_untracked_modifications $number_of_untracked_deletions $number_of_untracked_adds number_of_untracked_changes $number_of_cached_modifications $number_of_cached_adds $number_of_cached_deletions $number_of_cached_changes"
}

read number_of_untracked_modifications number_of_untracked_deletions number_of_untracked_adds number_of_untracked_changes number_of_cached_modifications number_of_cached_adds number_of_cached_deletions number_of_cached_changes < <(get_git_statuses(5 8)

But as, I already said, I'm a beginner in bash, and I'm not sure to have a good point of view.

[jderusse]

nb: It don't use zsh, I ignore if it work or not...

[arialdomartini]

Hi @jeremy-derusse, I like your approach.

In fact, I hate that I'm returning 24 parameters. I struggled to understand how to return a dictionary, but as a matter of fact, bash 3 does not support dictionaries, and arrays can't be returned. This sucks a lot. Bash 4 and zsh solve most of those ugly limitations, but a lot of people still stick to bash 3.

Reading your proposal I think that a good approach could be:

• the main oh-my-git file makes available a bunch of methods like get_current_action(), get_git_statuses() and so so on
• each theme is free to invoke and use one or more of them

I understand you tend to ignore zsh; I'd love to be free to take into consideration just one between bash and zsh, but some of oh-my-git users are on zsh, some others on bash. I could split the repo into 2 repos, but I'm not sure it would be the best solution. Thinking on it in the next days.

Thank you for the idea, I think I'm going to implement it.

[jderusse]

I misspoke my last comment, (In french we use the same word for "don't know" and "ignore"). I didn't mean, that I ignore zsh's user. I mean that I don't know if my proposal works or not in zsh. It's important that oh_my_git works with both bash and zsh, and I thinks, it'll be better if it's works with the same code and same repo.

I also don't know if it's works with bash 3 :(

If you refactor the base.sh to use smaller functions, I'll glad to create a PR which add my theme :)

[arialdomartini]

Oh! Didn't know that fact about French! Funny! Ok, I'll work on this feature the next days. Stay tuned!

[arialdomartini]

(Well, thinking about that, in Italian as well "ignoro" means both "I don't know" and "I don't care". Funny)

[maxailloud]

What is the status of this?

I'm very interested by this feature. And I know I'm not the only one.

And btw awesome job.

[arialdomartini]

Hi @maxailloud ! I didn't start yet. By the way, could you please give us your personal opinion? Would you use a variable for selecting the theme, or would you like to select the themes by the means of source commands? I'm still thinking on how to manage a set of themes in bash.

[maxailloud]

Ok no problem.

Managing themes by the means of source commands sounds like a good solution to me.

[atav32]

+1 looking forward to this

[pdostal]

For example I'd like to use different colors :art: So it'd be nice to create my own custom theme :yum:

[masukomi]

Just as a note this is the version of bash I've got on my mac running Yosemite.

~/workspace  ➜ sh --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin14)
Copyright (C) 2007 Free Software Foundation, Inc.

[masukomi]

I vote for solution 1

include in .bashrc either source ~/.oh-my-git/theme-x.sh for the theme x or source ~/.oh-my-git/theme-y.sh for the theme y, where each theme must include source base.sh

[luzma87]

Any updates on this? I really like the compact display :)

[maxailloud]

Where are we on that display/theme?

[jderusse]

I personnaly switched ton powerline where I implemented a plugin : https://gist.github.com/jderusse/b78505a6330c2d5ca98bdb60a6e42afb

[maxailloud]

Ok.

But maybe @arialdomartini has worked on a theme feature and this interest me.