Spaceship-prompt: Display fish-like path when shrink-path plugin is enabled in oh-my-zsh

[webknjaz]

Is your feature request related to a problem? Please describe.

I want to see a shorter representation of the current working directory path. Just like Fish shell does.
There's a plugin in omz with a shim for that: https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/shrink-path

Describe the solution you'd like

I'd like spaceship to detect a function called shrink_path and use it instead of pwd, probably switchable.

Describe alternatives you've considered

Monkey-patching the theme.

[guilhermeleobas]

Hi, I can work on this one.

[guilhermeleobas]

@salmanulfarzy The file linked by @webknjaz has a WTFPL license and oh-my-zsh is MIT-licensed. Can I just copy and paste that file into spaceship-prompt?

[salmanulfarzy]

Thank you @webknjaz for the suggestion and @guilhermeleobas for picking this up. I'm concerned about including external functions as such because of maintainability.

The file linked by @webknjaz has a WTFPL license and oh-my-zsh is MIT-licensed.

If we decide to include this, We should be fine by crediting original author and OMZ for further improvements.

[salmanulfarzy]

While the paths are shrunk how should we handle SPACESHIP_DIR_TRUNC and SPACESHIP_DIR_TRUNC_REPO. Truncating with shortened path doesn't much help, right ?

Without considering the above variables, May be we could simplify the function to somethings like this ?

function shrink() {
  local paths=(${PWD/$HOME/\~}) 'cur_dir'
  paths=(${(s:/:)paths})

  for directory in ${paths[@]}
  do
    cur_dir+="${directory:0:1}"
    cur_dir+='/'
  done
  echo ${cur_dir: :-1}
}

What do you guys think ?

[webknjaz]

Honestly, it'd be easier for me to comment on PR. Since I don't have a knowledge of the codebase it is hard for me to get a context.

P.S. I asked for detection of omz's fun, because I wanted to be able to just enable that plugin, without having to configure spaceship additionally. Can this be a part of the configuration API?

[salmanulfarzy]

I asked for detection of omz's fun,

We specifically restrain from including/depending on external plugins and frameworks for prompt.

Honestly, it'd be easier for me to comment on PR.

I'll leave to @guilhermeleobas for the PR.

[guilhermeleobas]

@salmanulfarzy, I think it's best to not truncate the last dir, just like what fish shell does. Also, I didn't get what the variables you mentioned are supposed to do. One activates the function while the other controls how many dirs are truncated?

Nevertheless, maybe a simplified version is not what @webknjaz is looking for. The original shrink_path has some nice features such as dir disambiguation.

[maximbaz]

My 5 cents: I don't think putting everything into one dir section is a good idea, even now this section is unnecessary large. Currently we have two separate if branches in that section that share _no code at all_, so what's the point of bundling them in one file?

I believe in small simple sections that do one job, and so in my mind there should be 3 different sections:

• dir (that behaves like $SPACESHIP_DIR_TRUNC_REPO == false)
• dir_repo (that behaves like $SPACESHIP_DIR_TRUNC_REPO == true)
• dir_shrink that basically calls shrink_path function.

And it's totally fine to depend on the existence of this function in dir_shrink, just like docker section depends on docker, golang section depends on golang, and so forth.

[salmanulfarzy]

• SPACESHIP_DIR_TRUNC : Currently number of components in dir section is determined with this variable.
• SPACESHIP_DIR_TRUNC_REPO : How the path should be displayed on git repositories where path is truncated till repo root.

So, What happens if a user have shrink_path and configured above variables. How do we truncate the shrunken path ?

I'm fine with adding those functionality to spaceship-prompt as utilities or functions in sections. But do not favor checking _plugin(s)_ from frameworks to render prompt.

original shrink_path has some nice features such as dir disambiguation.

https://stackoverflow.com/a/45336078

function spwd {
  paths=(${(s:/:)PWD})

  cur_path='/'
  cur_short_path='/'
  for directory in ${paths[@]}
  do
    cur_dir=''
    for (( i=0; i<${#directory}; i++ )); do
      cur_dir+="${directory:$i:1}"
      matching=("$cur_path"/"$cur_dir"*/)
      if [[ ${#matching[@]} -eq 1 ]]; then
        break
      fi
    done
    cur_short_path+="$cur_dir/"
    cur_path+="$directory/"
  done

  printf %q "${cur_short_path: : -1}"
  echo
}

[guilhermeleobas]

Hi all,

@salmanulfarzy, I wasn't aware of the existence of such variables. Also, I tend to agree with @maximbaz. The way dir is coded today makes SPACESHIP_DIR_TRUNC and SPACESHIP_DIR_TRUNC_REPO mutually exclusive, even though they aren't.

I will make a PR splitting dir in 3 different sections.

[salmanulfarzy]

there should be 3 different sections

Similar methods was suggested to git section by @olets at #391. So can we move this along with it to v4.0.0 ?

[olets]

Looking for shrink-path is cool!

But re: "3 different sections": I'm actually no longer sure that supplying a variety of flavors is a good idea — #492

[webknjaz]

But do not favor checking plugin(s) from frameworks to render prompt.

What if we put it this way: it would be nice to have an API for replacing bundled shim with any other executable with same interface user supplies. It could be that function from omz or anything custom.
Sounds reasonable? I think it will add optional flexibility without adding a dependency on third-party.