@mattmc3 What would you like to set these to in practice? I just want to see how the prompt would look.

One more example using a post-prompt for to indicate a Python venv:

function VIRTUAL_ENV --on-variable VIRTUAL_ENV
    if test -n "$VIRTUAL_ENV"
        set -g fish_prompt_pwd_dir_length 1
        set -g hydro_pre_prompt ""
        set -g hydro_post_prompt "🐍 "
        set -g hydro_multiline false
    else
        set -g fish_prompt_pwd_dir_length -1
        set -g hydro_pre_prompt "\n"
        set -g hydro_post_prompt " "
        set -g hydro_multiline true
    end
end && VIRTUAL_ENV

Thanks, @mattmc3. Would this feature also supersede hydro_multiline?

It could. In that case we'd need to deprecate/repurpose the multiline variable, and then if you wanted a more spacious prompt you'd do set --query hydro_pre_prompt || set --global hydro_pre_prompt "\n\n". Since deprecating a variable would be a breaking change, I'll leave that call to you.

See PR #36 for an alternative implementation that handles mutiline support.

Thank you, @mattmc3. I'm still not sure if I want to add this feature, but I'm thinking about it.

Question. Would a new "sparse" (as opposed to "compact") configuration variable solve your use case here? I'm not suggesting we add that yet, just curious.

The genesis of this request is from someplace else entirely. What I'm actually looking at is other prompts like Starship, which let you customize a ton of components of your prompt: https://starship.rs/config/#prompt. Starship isn't fast (at least, compared to Hydro), and I definitely don't think Hydro should become like Starship, but having a simple way to extend Hydro answers a lot of the customization need without putting additional burden on Hydro to support all-the-things the way the Starship devs have to.

The other option I was considering is forking out the clever git status portion of the prompt (similar to what Zsh has here: https://github.com/romkatv/gitstatus). Having these features separate would let Fish users compose a prompt of their choosing tailored to their specific needs, and makes the Ruby/Python/Node/Go/Rust/etc customizations available with a simple user-managed Fish script. This method seems overkill when Hydro does 95% of what I need in a prompt, but could use just a small hook or two to add customizations to it. Whitespace management is only one small part of that customization.

If there's another idea I hadn't considered, I'm open to that.

Fair enough. Should we also consider adding a right prompt?

Another option is introducing a new variable: $hydro_prompt_items. We would iterate over the list of items and figure out how to print the prompt from there. This would allow you not only to add new items but to reorder the built-in items.

set --global hydro_prompt_items _hydro_git _hydro_pwd _hydro_prompt

function fish_prompt --description Hydro
    if set --query hydro_prompt_items
        set --local prompt 
        for item in $hydro_prompt_items
            switch $item
                case _hydro_pwd
                    set prompt "$prompt$_hydro_color_pwd$_hydro_pwd$hydro_color_normal"
                case _hydro_git
                    set prompt "$prompt $_hydro_color_git$$_hydro_git$hydro_color_normal"
                case _hydro_cmd_duration
                    set prompt "$prompt$_hydro_color_duration$_hydro_cmd_duration$hydro_color_normal"
                case _hydro_prompt
                    set prompt "$prompt$_hydro_prompt$hydro_color_normal"
                case \*
                    echo set prompt "$prompt$_hydro_color_$$item$$item$hydro_color_normal"
            end
        end
        echo -e "$prompt "
    else
        echo -e "$_hydro_color_pwd$_hydro_pwd$hydro_color_normal $_hydro_color_git$$_hydro_git$hydro_color_normal$_hydro_color_duration$_hydro_cmd_duration$hydro_color_normal$_hydro_prompt$hydro_color_normal "
    end
end

main ~/C/@/hydro 1.3s ❱

I like that a lot. That’s a way better solution. Then the user just adds items, or overrides the prompt and displays the items themselves.

I think that's how Tide does it. I don't want to allow too much customization, though. I think Tide already excels at that.

Having said that, I'm not sure about this particular implementation yet. It's not slow, but it hurts perf a tiny bit, which I'd like to avoid or diminish somehow (if possible).

While I'm open to exploring the idea of addons, components, or whatever we want to call them (#37), I won't be introducing specific pre/post customization variables, so closing as not planned.