Add handle for active prompt.

[dthree]

When inquirer.prompt is called, the UI object is returned. However, in the course of cycling through prompts, the currently active prompt is never exposed to either the UI object nor inquirer itself.

I added a simple handle that cleans itself up, and exposed a public function to the UI object returned in a prompt, so that one can programatically assess and handle the current prompt.

Usage example:

var prompt = inquirer.prompt(options, function(result) {
  console.log(prompt.activePrompt()); // returns undefined - the prompt has terminated.
});
console.log(prompt.activePrompt()); // returns the prompt object

This would be tremendously helpful for programmatic use of Inquirer.js as I can then hook in keypress events and control the active prompt in a proper fashion. This is needed to finish this pjt:

https://github.com/vorpaljs/vorpal-less

:)

[dthree]

Added a second commit that so that the Inquirer UI fires an event when the prompt changes. In this way, you can programmatically determine when each question gets asked.

Do these changes look okay to you?

[SBoudrias]

I have a really hard time to see what you're trying to achieve. It looks to me like you want to overwrites prompts methods?

If that's the case, why not overriding the prompts types with inquirer.registerPrompt()?

About the "next" event, why not use the reactive API?

[dthree]

Thanks for your answer. Let me try to clarify.

What I'm really running into is that Inquirer.js is very well designed as a UI for a CLI user, but it (intentionally, nothing wrong with it) doesn't provide much support for programmatic control of the existing UI components on the fly.

Vorpal.js is built off of Inquirer, and I expose all prompts (such as lists, etc.) through it. What Vorpal does do with these however, is gives more fine-grained control of those prompts so that one can do some fancier things with them, such as:

• Edit the user content of a prompt on the fly. For example, Vorpal provides an API for tabbed autocompletion. So when the user presses [tab] on an Inquirer input, Vorpal has to access that input, edit the text and then redraw it.
• Edit the message of an input on the fly. For example, vorpal-less is a JS implementation of the less unix command. When running vorpal-less, when you hit the end of the content, the message needs to change from : to an inverted END string. Vorpal does that with any inquirer UI piece.
• Listen for key-presses on any prompt. For example, in less and vorpal-less, almost every key does a custom function, i.e. navigates the content, pulls up help, quits the app, etc.

---

So in summary, I'm simply trying to use vorpal to make inquirer more powerful and flexible from a programmatic perspective. I don't want to register a new UI component for Inquirer as the existing ones are perfect, and I want someone to be able to use and manipulate any of them.

Right now, Vorpal does do all of the above, however it's way too hacky and messes with your internals too much. Properly exposing the active prompt lets me do the above far more gracefully (and stably).

Does this answer your question?

---

On RxJS, I can totally do that. Just need to study up on it a bit because it's honestly still magical and new to me. :)

[SBoudrias]

You can still access the Inquirer prompts (require('inquirer/lib/prompts/input')), modify them with your extra behavior and re-register them on Inquirer.

[dthree]

Sigh. I guess I can, however I then need to start re-writing your methods, which gets super messy, and as soon as you do an Inquirer update, it's going to break something.

All I'd really like to do is expose a UI Component (not change its methods) while it is being prompted, and then I can cleanly handle the rest. If you don't like the way I did it, I can totally change it to whatever you see as the best way to go about it: just let me know.

Any chance we can just do this? 😃

[sindresorhus]

👍 I too wish Inquirer were more easily programmatically extendable.

[dthree]

@SBoudrias @sindresorhus perhaps we could discuss a roadmap in this direction that we all can agree on and that doesn't mess with Simon's original goals in making Inquirer. I've had a lot of experience now messing with Inquirer's internals, so I could lay out what I think would improve it in a programmatic sense, and wouldn't mind helping get done whatever we agree on.

What do you guys think?

[sindresorhus]

👍 I want things like this to be possible: #46

[dthree]

👍

I'm currently finalizing the vorpal API for the following methods:

ui.cancel: Cancels Inquirer prompt
ui.submit: Submits the Inquirer prompt as if the user pressed [enter].
ui.pause: Pauses Inquirer prompt
ui.resume: Resumes Inquirer prompt
ui.imprint: Logs current prompt text and delimiter and returns to the same prompt (good for tabbed auto-completion).
ui.delimiter: Changes the Inquirer message and redraws.
ui.input: Re-writes user input mid a prompt (like #46 above).
ui.redraw: Exposes log-update.
ui.redraw.done: Exposes log-update.done, and then refreshes Inqurier's prompt after completion.
ui.redraw.clear: Exposes log-update.clear.

Most of these dig deep into the internals of Inquirer. This is my wishlist: I would love if Inquirer exposed functionality for these! 🌟

[dthree]

Just put together better descriptions of the functionality I'd love to see in Inquirer.

(Need to work more on the pause and resume methods. They're way too hacky still.)

[dthree]

@SBoudrias I managed to figure out a workaround for now on this issue, so I'm going to close the PR. You don't seem to excited about it haha.

Anyway, if you ever want to get around to making Inquirer more programmatically accessible, let me know and I'll gladly help!

[SBoudrias]

@dthree that'd be great. I'd just like it to match closer the api design style of Inquirer.