feat(@clack/prompts): multiline support

[orochaa]

Multiline Support

Support multiline texts either with \n, or long ones that exceed terminal width, without breaking the layout

List of supported prompts:

• text
• password
• confirm
  • Is just yes/no
• select
• selectKey
  • It was made to handle short options
• multiselect
• groupMultiselect
  • It was made to handle short options
• note
• intro
• cancel
• outro
• log
• spinner

How to test

// From ~/clack
git remote add test-multiline https://github.com/Mist3rBru/clack.git
git checkout -b test-multiline
git pull test-multiline ml-example
pnpm build
cd examples/basic
npx jiti multiline.ts

Closes #101
Closes #132
Relates #135 #111 #35

[changeset-bot]

🦋 Changeset detected

Latest commit: 62939c8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clack/prompts	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cpreston321]

@Mist3rBru Straight killing it man 🙏🏼

Question:

1. Shouldn't we support multiline at the core level vs trying make it work with @clack/prompts? The only reason I ask because to me I would think core will support the main functionality and prompt would extend that functionality.

[orochaa]

I don't see how to implement it on @clack/core, since it strict resolves the issue when a new line doesn't start with its corresponding symbol from @clack/prompts

[orochaa]

Maybe we can add formatTextWithMaxWidth as an util function on @clack/core, to use it on a future Textarea prompt, and import this util from @clack/core to @clack/prompts

[cpreston321]

I think we will need to pass a custom formatter func within the render function or expose a way for core to understand what is input vs styling.

As I think this could fix support temporary for prompts, I do feel like core will have to know so it can easily extended for other people not wanting to use @clack/prompts.

[cpreston321]

Or we need to a way to expose what is the input text coming from core then do some special format around the input. I'm trying to think a neat way to handle it.

[cpreston321]

@Mist3rBru I think for now you can keep this PR open and create a new draft pr that will mutate core functionality for a POW if you want. So we can get @natemoo-re to check it out.

I'll do some more testing for the time being.

[orochaa]

@cpreston321 what if we create a method on core Prompt called format or style, then all prompts can call render: () => this.format(msg)?

[cpreston321]

Are you thinking of creating a new function within prompt called format: (msg: string) => string like validator: ()? If we go this route -- I think it would be good to make it super flexible.

I am thinking of something that has a template then having a replacer for input styling. To keep things streamed line. (thinking out loud). Almost like template replacer with variables {{title}}, {{input}}. So it can be reused.

[cpreston321]

@Mist3rBru Found some formatting issues and also a bug with the format function. It's a dim color for the | below the input and when selecting yes on install it errored out.

....

[orochaa]

@cpreston321 now must be right.

[cpreston321]

Hey @Mist3rBru something still seems off:

How it should look:

[orochaa]

@cpreston321 I forgot the cancel prompt

[cpreston321]

Hey @Mist3rBru it looks like the default state looks off too it should look like this:

┌   create-app 
│
◇  Where should we create your project?
│  ./sparkling-solid
│

not

┌   create-app │
◆  Where should we create your project?
└  ./sparkling-solid

[orochaa]

@cpreston321 now must be right 🙏.

[cpreston321]

@Mist3rBru I fixed the styles in this branch but if you want to copy them over then fix them here you can!

e365d60

[orochaa]

Thanks @cpreston321, it is merged!

Now what should I do? Keep with this branch, merge it with the #143, or look for another approach to implement this feature.

[cpreston321]

@Mist3rBru #143,

I think it's a step in the right direction. I also think it might need some fine tuning for it to be fully there.

In my head I would think there would be a template and spot for input to support the multi line support for formatting in the terminal almost like a wrapper and within a input. I just an easy way to leave styling up to the user and we can focus on core functionality.

Within prompts we create a lot of duplicate styles but really the only thing that is the variant of the input and colors. If there was to define a base template/wrapper around the input, so that we can control the input with multi line support.

I would think people would want to setup a custom wrapper for each prompt including state variants but also making the api very simple and easy to understand. Which I don't think is fully there.

My thought (will fallback to base @clack/core template/wrapper) :

 __________________________________
 |
 |  custom style template/wrapper   
 |
 | |-----------------------------|
 | |  input (core formating)     | 
 | |-----------------------------|
 |
 |
 |__________________________________ 

I am just thinking out loud here but this is something I would imagine. I don't want the user to think about it too much.

Making the api feel really easy, fluent, customizable is key.

[cpreston321]

Also @Mist3rBru While playing around with multiline support I encounter this

Screen.Recording.2023-08-15.at.1.20.31.PM.mov

Have any idea ?

[orochaa]

@cpreston321 It is almost fixed, there is an annoying [7m from cursor that shows only when the prev line is on last char that i coundn't solve

[orochaa]

@cpreston321 inner line break and cursor are fixed. I am going to close it, and focus on PR #143

[cpreston321]

That sounds good, I think that will a better direction for the library -- since it will be at the core. I will add my input over there.

Hopefully Nate can get some input over there too!

Thanks,
CP 🚀