-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More customization #22
Conversation
This new script - is not related to a prompt shell anymore, except for color codes - is using configurable color codes - doesn't leak variables - offers configurable color codes per symbol
Amazing job, pal! Really impressive! Hopefully I'll merge it on Monday. |
Hi Brice. Before merging your pull request, I need to make it compatible with the current zsh themes.
so they would break right after the merge. I also noticed that the
which uses the old names. The last two issues I noticed:
I think most of these problems could be fixed updating the variables names in What do you think? |
Oh you're right I forgot to update the vars and I removed the So this might be possible to reintroduce a Also I prefer to keep the I'll fix the issues you raised later this week ;) Also it's not in the pipeline yet, but I wondered if oh-my-git could have a place in the oh-my-git repo (in this case the variables must be uppercase to conform the coding norm of oh-my-zsh). Or if it is enough to put the script in the oh-my-zsh custom plugin folder |
Take your time! In the meanwhile I'm going on reviewing your code.
I'd love to! How could I achieve this? |
For oh-my-zsh, I think you can just make a simple PR there. For the moment until I created the following file Here's a screenshot of how it looks Also to be accepted the code needs to follow the coding style https://github.com/robbyrussell/oh-my-zsh/wiki/Coding-style-guide |
Hello I've fixed the issues, now it should work fine on bash or on zsh. I added a new Also I fixed the color codes for bash in the example, as they must be wrapped by |
Great! In this screenshot, the first line after I'm trying to understand why checking your code. |
My fault! I just understood that there's the option |
(By the way: I hate to be such a perfectionist, but, you know, we must ensure that the new version won't introduce any new bugs or unexpected behaviours. I'm really sorry that I'm forcing you to discuss every single line of your great contribution: I hope you won't mind ;) |
@@ -28,20 +28,26 @@ if [ -n "${BASH_VERSION}" ]; then | |||
: ${two_lines:=true} | |||
: ${finally:='\w ∙ '} | |||
: ${use_color_off:=false} | |||
: ${print_unactive_flags_space:=false} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this flag: it's a big improvement of the previous implementation.
In order to make the new prompt perfectly compatible with the previous one, I'd use true
as the default value.
: ${print_unactive_flags_space:=true}
No problem, I understand that ;) I set the |
I'm eager to merge that one ;P See : https://github.com/bric3/oh-my-git/blob/git_current_action/git-info.sh |
Yes, I know! I've seen your next commits (your repo is one of my remotes ;) |
(I also think that the "current action" feature is really really cool!) |
Ok, we are almost done. One of the flags that I should add, in order to make the theme render like before, is
would strip those spaces away. I have prepared the fixes for the 2 themes, so I'll be able to merge this pull request and publish the new version for the theme, as soon as this issue has been fixed. So far, this was the last problem I was able to spot. Cheers! |
During my tests I didn't have to use any spaces, I think this is probably the same issue as with bash prompt with unprintable characters. (When the prompt is redrawn the terminal thinks it is wider that it actually is, and depending on the configuration the actual prompt location may vary.) In my setup I don't use $RED or escape codes directly but rather the following color codes documented in the prompt expansion section of the zsh documentation. So color codes must be wrapped in Also I don't know where these variables ( Instead I defined the colors this way on ZSH :
|
I'm also very eager to merge this! Unfortunately, I am not able to get rid of some weird problems with your code. I'm very very sorry, because I'm looking forward to including all your new features in oh-my-git repository. This is the current state: I created 2 forks for us to test
rather than
Those 2 repository are exactly what I'd expect to obtain after the merge of your pull request. I'm using them to perform a last test, and so you could do (in the case you want the rights to push on them, just ask me, I'll be happy to include you) Using antigen, I configured my zsh with this
This is what I obtain: Can you spot the two issues? The first is a whitespace before the ❤ symbol. This is really weird, and I spent 2 hours trying to understand why this is printed in zsh only. Bash does not displays it. I wonder if this can depends on
Anyway: this is just a minor problem. Unlucky, there's a second issue: whenever you checkout a commit detaching from branches, a See the comments inline for this issue Cheers! |
if [[ ${just_init} == true ]]; then | ||
oh_my_git_string="${oh_my_git_string}${detached_color}detached${reset}"; | ||
else | ||
oh_my_git_string="${oh_my_git_string}${detached_current_commit_color}(${current_commit_hash_abbrev}\)${reset}"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out that ${current_commit_hash_abbrev}
is never assigned.
I think the line should be
oh_my_git_string="${oh_my_git_string}${detached_current_commit_color}(${current_commit_hash:0:7})${reset}";
(with the :0:7
and without the extra \
)
Alternatively, the ${current_commit_hash_abbrev}
must be defined.
Since you introduced a new variable, I suppose you just missed a line.
You're welcome ;) Well spotted, I totally missed that one. I think I see where is the issue with the leading space. And I believe this is due to string concatenation. the double echo trick, only collapse contiguous spaces in to one, it doesn't remove them. I wonder of using |
By the way, I'm not using antigen at all, just the bunch of scripts available on oh-my-zsh It's probably the one of the most intensive work I have ever done in shell, shell scripting is kinda booby trapped ;) About the new repos they seem to look good. The powerline theme needs the new color code though. |
I'd love to see it! Is it public? As for the current state of the pull request, I'm going to update the other theme as well. |
I've made some PRs on the oh-my-zsh repo, but they are not yet integrated. As for the theme I didn't updated it yet on my fork ; it still uses the git plugin of oh-my-zsh and non submitted works. I think once my PRs are merged there I will probably push the updated modification. But I may create a new project that install easily in the not yet documented
I think the last two are now fixed ; ie the leading space issue and the commit hash. I haven't looked at every combination, but I don't think there's any other (significant) bug ? |
I'm using ZSH 5.0.5 so that shouldn't be an issue (well to be sure the changelog has to be checked). For example the following lines remove the leading and trailing blank spaces just fine in ZSH SOME_VAR=" a b "
echo "|${SOME_VAR##+([[:space:]])}|" # removes leading whitespace characters
echo "|${SOME_VAR%%+([[:space:]])}|" # removes trailing whitespace characters However checking again I've discovered that these expansions don't work well in bash (that could mean there's some option to set for bash). It seems the correct way in bash is the following : SOME_VAR=" a b "
echo "|${SOME_VAR#"${SOME_VAR%%[![:space:]]*}"}|" # removes leading whitespace characters
echo "|${SOME_VAR%"${SOME_VAR##*[![:space:]]}"}|" # removes trailing whitespace characters A |
Using your theme, without any modifications in the theme or the script here's what I got : |
I've externalized the trimming function, I didn't change the logic, but it may help to narrow down the issue on your box. |
Will now display curent git action (REBASE-i, REBASE-m, REBASE, MERGING, CHERRY-PICKING, etc...) Also adds `oh-my-zsh.hide-status` check before doing anything
Hey, I'd like to inform you that I've created a separate project from this pull request, I've reworked the install to be tailored for oh-my-zsh. Of course most credit must go to you. Let me know if you want to change the credits in a way or another. ⇒ https://github.com/bric3/oh-my-zsh-git/ Cheers, |
Man, this is an amazing work! My fault that I wasn't able to fix the only, little issue that prevented me to merge your PR: I'd say it has been a luck, since it took the the birth of your project! |
Well bash stuff have quirks ;) If you see issues you can fix don't hesitate as well to make a PR then :) |
@arialdomartini looks very good ! |
Man, I included your |
:) |
This new base script (
git-info.sh
)oh-my-git.plugin.zsh
)display_git_symbol
)use_color_off=false
and flag is off, toggable withprint_unactive_flags_space
)git config --get oh-my-zsh.hide-status
REBASE-i
,REBASE-m
,REBASE
,AM/REBASE
,MERGING
,BISECTING
,CHERRY-PICKING
)Note default color codes might not work well on ZSH, when this method is echoed on `RPROMPT``, use the following ZSH compliant color codes.
For example: