fix: spaces and uppercase characters in multiline input

[MattStypa]

What does this PR do?

Fixes multiline prompt typing so spaces and uppercase characters are inserted correctly.

See #529 for details.

Changes

• Use a local arrow-key action set in multi-line prompt handling.
• Fix character insertion to preserve spaces and shifted uppercase input.
• Add regression tests for space insertion and shift-uppercase typing.

Closes #529

Type of change

• Bug fix
• Feature
• Refactor (no behavior change)
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• I have added a changeset

AI-generated code disclosure

• This PR includes AI-generated code

[changeset-bot]

🦋 Changeset detected

Latest commit: 19255e0

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

This PR includes changesets to release 2 packages

Name	Type
@clack/prompts	Patch
@clack/core	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

[pkg-pr-new]

• @example/basic

• @example/changesets

  npm i https://pkg.pr.new/@clack/core@534
  

  npm i https://pkg.pr.new/@clack/prompts@534
  

commit: 19255e0

[gameroman]

This can probably be added to utils/settings as arrowKeys

[dreyfus92]

i think this might break a couple of real cases:

• paste: terminals usually send pasted text as a stream of keypresses with shift: false per char. since the base Prompt.onKeypress already lowercased char, we'd never re-uppercase here, pasted mixed case ends up all lowercase.
• capslock without shift: some emulators send the upper-cased char with shift: false too, same deal.
  the real root cause is that Prompt.onKeypress lowercases char before emitting 'key'.

probably cleaner to just insert from key.sequence (the raw bytes, original case) and skip the shift dance entirely

wdyt @43081j ? 👀

[MattStypa]

I based this on existing code here:

clack/packages/core/src/prompts/select-key.ts

Line 26 in 54be8d7

const casedKey = caseSensitive && keyInfo.shift ? key.toUpperCase() : key;

But I see how that use-case is different.

Let me take a closer look.

[MattStypa]

@gameroman, @dreyfus92

Thank you for your feedback. The PR has been updated.

Please let me know if changing how prompt.ts emits key events is not the right solution in your opinion.

[43081j]

i'm not sure about this as it touches more than it needs to.

cursor events purposely can be any Action, arrow keys don't hold any meaning here other than being some defaults. i.e. we don't need a concept of "arrow keys" or a new settings entry, as they are indeed just "actions".

i think the only changes you need are:

1. the key handler should pass char as-is (no lowercasing)
2. select-key refactor to account for this
3. update select-key test since it had the wrong casing already

you have all these so i think it looks good if we drop the arrow key stuff

[gameroman]

cursor events purposely can be any Action, arrow keys don't hold any meaning here other than being some defaults. i.e. we don't need a concept of "arrow keys" or a new settings entry, as they are indeed just "actions".

Do you mean they don't need to be in the settings file or don't need special handling?

Looking at the code, CursorAction is probably a better name for them instead of ArrowKeyAction

[43081j]

im saying none of the changes around "arrow keys" are needed to fix this bug

[MattStypa]

im saying none of the changes around "arrow keys" are needed to fix this bug

@43081j Im curious what your suggestion to fix the space key issue is.

At the moment, the multi-line key handler checks keys against settings.actions (which includes space) and returns early.

see here

There are a many valid ways to address this. Initially, I scoped the set of cursor keys to multi-line.ts (see here).

[43081j]

i think that is a bug in the multi-line prompt.

clack/packages/core/src/prompts/multi-line.ts

Lines 92 to 95 in 54be8d7

	if (key?.name && settings.actions.has(key.name as Action)) {
	this.#handleCursor(key.name as Action);
	return;
	}

here we check that the key is an "action" key, and treat it as a cursor action if it is.

but the multi-line prompt doesn't control its cursor actions based on the actions keys. it is hard coded to use the arrow keys here:

clack/packages/core/src/prompts/multi-line.ts

Lines 47 to 58 in 54be8d7

	case 'up':
	this._cursor = findTextCursor(this._cursor, 0, -1, text);
	return;
	case 'down':
	this._cursor = findTextCursor(this._cursor, 0, 1, text);
	return;
	case 'left':
	this._cursor = findTextCursor(this._cursor, -1, 0, text);
	return;
	case 'right':
	this._cursor = findTextCursor(this._cursor, 1, 0, text);
	return;

the settings can't override that.

so its basically a bug i think - that we shouldn't be checking settings.actions. we should just have a hard coded check for if it is an arrow key or not.

so you were on the right track, but not as a change to the core settings or types. this is just a separate, one-off hard coded set of keys a user can't configure (specific to the multi-line prompt).

[MattStypa]

@43081j updated