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
WIP - shorten directory relative to repo root #465
base: master
Are you sure you want to change the base?
Conversation
03a8d80
to
b9390a3
Compare
Alright, detecting the root is implemented for all supported VCSs (afaict). I've also had to fix up the awk script to run on OSX, but I could imagine it being broken elsewhere since the |
I've cherry-picked your second commit ("Fix up awk script and make readable") as it was good and independent of the rest of this PR. Please rebase your branch on master and push -f. |
b9390a3
to
406dc26
Compare
Alright, done. |
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.
This implementation (even with my remarks applied) will break the bash with LP_ENABLE_SHORTEN_PATH=0 and PROMPT_DIRTRIM set
case.
liquidprompt
Outdated
case "$LP_VCS_TYPE" in | ||
git*) git rev-parse --show-toplevel; ;; | ||
hg) hg root; ;; | ||
svn) svn info | grep 'Working Copy Root Path' | cut -d' ' -f5-; ;; |
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.
Add LANG=C
liquidprompt
Outdated
# * Show the relative path from the root to "$PWD" in a different color | ||
_lp_shorten_vcs_path () { | ||
local root x | ||
root="$( |
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.
Move the root
assignment inside each case.
liquidprompt
Outdated
)" || return | ||
# trim leading and trailing whitespace, as well as a potentially trailing slash | ||
root="${${${root##*[[:space:]]}%%[[:space:]]*}%/}" | ||
if [ ! -z "$root" ]; then |
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.
if [[ -n "$root" ]]; then
liquidprompt
Outdated
@@ -1802,6 +1825,9 @@ _lp_set_prompt() | |||
# end of the prompt line: double spaces | |||
LP_MARK="$(_lp_sr "$(_lp_smart_mark $LP_VCS_TYPE)")" | |||
|
|||
_lp_shorten_path # set LP_PWD | |||
_lp_shorten_vcs_path |
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.
You are calling both lp_shorten_path
and _lp_shorten_vcs_path
. This is inefficient as only the result of one of them will matter.
- Instead of calling both,
_lp_shorten_vcs_path
should delegate to_lp_shorten_path
in case it does not fillLP_PWD
- The call to
_lp_shorten_vcs_path
should be in aif [[ -n "$LP_VCS" ]]
block
From the comments above it seems you want to do either trimming or relative dirs? What do you think about combining the two, i.e. generalising the code to trim and then apply it as a last transform on whatever is present? |
No. I'm just telling the this particular user configuration has been so optimised in liquidprompt that One major concern is stability. I like your relative dirs idea (so once we have a good implementation I want it to be enabled by default), but I want existing users who upgrade to still be able to switch it off and go back to the previous behaviour.
This is interesting, but this is a much more tough project. It would require a more major rework of Liquidprompt and to be much more careful to not break things. |
liquidprompt
Outdated
# trim leading and trailing whitespace, as well as a potentially trailing slash | ||
root="${${${root##*[[:space:]]}%%[[:space:]]*}%/}" | ||
if [ ! -z "$root" ]; then | ||
if [ -n "$root" ]; then |
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.
Use double brackets: [[ ... ]]
instead of [ ... ]
What is holding me back a little is the lack of automated tests that I can run my changes through. Manually verifying is quite mundane for so many scenarios. I saw that many functions change global variables and are expected to be called in certain places under certain conditions. For example, I would have expected the shortening function to take as input the path to shorten and then return the new, shortened path, which would then be set at call site. I tried to make the added vcs shorten function to follow the existing pattern. Would you accept a PR to set up CI with say travis? |
Btw, I am trying to reduce the number of added commits as we go along, but we can certainly squash later on once we're happy to remove meaningless commits like the one that just came in ("Use double-brackets") from the history. |
👍 for Travis. But we have no testsuite. The test.sh is very old and does not work with the current code. Open another issue to discuss that. |
You can squash now if you want and push -f. |
ed7935d
to
200603c
Compare
Release Candidate v2.0.0-rc.1 is now out, which means that the rework is complete. This has merge conflicts that need to be fixed. Part of v2.0 was to support multiple path shortening methods and to highlight the VCS root and last directory. This gets close to what you were trying to do here, but none of the shortening methods show the path relative to the repo root (though all path formats will never shorten the repo root if Docs that would be helpful: And the And feel free to ask for help! |
demo: https://asciinema.org/a/21be5t92ib26uddrs9ehuaovr
I reported this as a feature request early last year: #349.
I have since brushed up on my shell skills and feel comfortable delivering the said feature set.
What's left to do?
$LP_COLOR_PATH_ROOT
) - input requiredThe way it's implemented it should be easy to add support for the supported VCS systems, provided they have a way to get the top-level directory... otherwise we might half to walk the file system, but I hope not.
I'd say supporting submodules as mentioned in the original issue would be a separate PR, but I personally lost interest in that feature.