opened
kusold
username_0
### General information

- Pure version: 872153f
- ZSH version: 5.5.1
- Terminal program & version: iTerm 3.2.0
- Operating system: macOS HighSierra 10.13.6
- ZSH framework: zplug

I have:
- [ ] Tested with another terminal program and can reproduce the issue: <!-- e.g. iTerm, etc. -->
- [x] Followed the [Integration](https://github.com/sindresorhus/pure#integration) instructions for my framework

### Problem description
I would like to add additional information to my preprompt (first line of the prompt), like this:

```
~/dotfiles master* ⇡ ruby:2.5.1p57 node:v10.8.0
❯  
```
I saw the `VIRTUAL_ENV` [advice](https://github.com/sindresorhus/pure/issues/221#issuecomment-236372279), but that's for replacing the `>` symbol.

What is the best way to achieve this? If there isn't a clean way, would you be open to a PR where I add a `PURE_PREPROMPT` env variable between these two [lines](https://github.com/sindresorhus/pure/blob/master/pure.zsh#L147-L148) or maybe above [here](https://github.com/sindresorhus/pure/blob/master/pure.zsh#L132)?
Inserting additional information in the preprompt
issue
closed
mafredri
username_1
issue
created
mafredri
username_1
This looks like a duplicate of https://github.com/sindresorhus/pure/issues/241, I'm closing this so we can keep the discussion there. Feel free to re-open if you think this is different.

But to kick this off, please see https://github.com/sindresorhus/pure/issues/241#issuecomment-255122601 for reasoning about this type of feature.

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
comment