Option to add prefix/postfix to preprompt line

[z0rc]

I want to add a couple of my own indicators to preprompt line: enabled virtualenv and mc/ranger subshell. I can easily define some functions or variables to return this info, all I need is a way for adding it to preprompt. Maintaining a fork is a last resort here, as I believe I wouldn't be a single person to benefit from such possibility.

[mafredri]

One possibility would be to purpose the psvar in the preprompt. If we then added %1v to the beginning, and %2v to the end, the user could set psvar to define his own head/tail of the preprompt.

Example:

But I'm not sure about this, I'm worried that a user might have predefined something in psvar which affects the prompt in a weird way, resulting in a bad initial user experience. Also, this would require extra documentation.

[z0rc]

Instead of using psvar we can use some custom variables like PURE_PREPROMPT_PREFIX. Simple note about them in readme should be sufficient.

Side node, referencing psvar as %1v has its own downsides, the escape sequences wouldn't be working as expected in those vars. http://www.zsh.org/mla/users/2005/msg00863.html

[mafredri]

Your suggestion would require two new configuration variables which is something we don't want. We don't want pure to be cluttered with a bunch of configuration options to fit everyones taste, the defaults should be good enough for most, and those who want more have the option to maintain a fork.

Also, the idea behind using psvar is to protect against expansion. If the user wants expanded content, he could take care of that himself, e.g. in his own precmd hook.

That said, I try to find ways to allow power users to tweak and extend pure without having to fork. This could potentially be one such instance given enough thought.

Also note that we are considering supporting virtualenvs in pure (see #221).

You might feel that adding these new configuration options are a reasonable request, however, we do not. But we're committed to always keep improving pure and all we ask is that you can keep an open mind and work with us, according to our principles, to make pure the greatest it can be 😁.

[mafredri]

This is a cross-post from #427 (comment) as I feel the information is relevant here as well:

---

[...]

That said, I'm not opposed to something that would allow this, in one way or another. I want Pure to be hackable, but not complicated. I have my own thoughts about what such an implementation could look like, but I have never gotten around to implement / experiment. But there are at least a few options I can think of (both include introducing a new markdown document, hacking.md or some-such):

1. Provide hooks that a user can use to hook into the Pure execution cycle, e.g. a user-defined prompt_pure_preprompt_postprocess function could perform additional manipulations to the preprompt before it is rendered. That's just a rough idea, naming, how to store the preprompt (e.g. psvar vs local variable), etc need to be figured out
2. Each part of the preprompt could be a separate function, with an array defining the order in which they should be invoked (each function adds it's own part to the preprompt, e.g. by assigning the next psvar entry or similar). The user could then modify the array that defines the order and add their own functions and/or change the order

[z0rc]

For example option 2 was implemented in fork https://github.com/intelfx/pure#custom-handlers. I'm successfully using it to extend prompt with my indicators at https://github.com/z0rc/dotfiles/blob/master/zsh/rc.d/08_pure.zsh.

[mafredri]

@z0rc Thanks for pointing it out, that does seem like a similar approach I had in mind (for nr. 2). I still think the post-processing / hook method is more powerful, though. And it could perhaps be re-used in other parts of Pure.

I mostly mentioned nr. 2 for brainstorming. There are some downsides that make it unappealing:

• Forces us to create as many functions as there are preprompt parts
• Increases API surface (can we rename functions without breaking anyones setup?)
• User must understand Zsh arrays (slicing)

[kusold]

User must understand Zsh arrays (slicing)

For option nr. 1, a user will realistically only be able to prepend or append to the entire prompt. Otherwise the string manipulation would probably get to be too difficult and brittle.

Option nr 2 allows users to insert data in the middle easily.

[mafredri]

For option nr. 1, a user will realistically only be able to prepend or append to the entire prompt. Otherwise the string manipulation would probably get to be too difficult and brittle.

I did not intend for it to be a string, it would still be an array (one for each segment, as in the code now), and understanding array manipulation would be beneficial here as well.

Option nr 2 allows users to insert data in the middle easily.

Not any more easily than via the hook where you would have access to the full preprompt array and can perform manipulations on it.

With option 1 you at least manipulate the preprompt directly instead of manipulating the order of functions that in turn manipulate the preprompt. In my opinion that's more straightforward.

[kusold]

I misunderstood how you were planning on exporting the data.

Would something like this work? I'm a bit of a shell scripting beginner so there might be better ways to achieve this.

After this line:
https://github.com/sindresorhus/pure/blob/master/pure.zsh#L133

# check that function is defined
declare -f prompt_pure_preprompt_postprocess > /dev/null;
if [ $? -eq 0 ]; then
  prompt_pure_preprompt_postprocess "${preprompt_parts[@]}";
fi

prompt_pure_preprompt_postprocess() {
  local my_prompt = ("$@");
  # manipulate here
 preprompt_parts = my_prompt;
}

[balki]

I would like to have the output of date in the prompt. I have different tmux windows for each purpose. For example, one terminal where I run updates. It is good to know when did I run the update last. A generic way to customize the prompt will be nice to have.