feature: Support multiline input in ask

[duguyue100]

Did you check the docs?

• I have read all the docs

Is your feature request related to a problem? Please describe.

I often write longer when using ask, and single line input box doesn't look great; it's also hard for me to do any modifications to the prompt.

Describe the solution you'd like

I understand that when using snacks, it only supports a single line input box. But essentially, we should have a fixed-width floating window that can take multiple lines of input, and ideally, I could also switch between normal/visual/insert mode for quick modification.

Describe alternatives you've considered

No other alternatives were considered.

Additional context

No response

[nickjvandyke]

Totally agree, thanks for opening an issue for this! I toyed with this a while ago but never refined it enough to merge. We can adapt snacks.input with the right configuration: setting height, max_height, and clearing buftype. And it already correctly sends to opencode as multiple lines on enter!

Refinements it could use though:

1. Shrink/grow height according to number of lines present, rather than a constant (some autocmd I presume?)
2. Set a max_width and enable wrap? This could be done separate of literal multi-line too, for a nice UX improvement. Needs more work though - snacks.input seems to still scroll the window as we type, rather than wrap.
3. Don't show the icon on successive lines?
4. Atm <CR> confirms the input, and <S-CR> appends it. So we can't just press enter (or the usual fallback) to type a newline in a multi-line ask. o works, but isn't very ergonomic. Maybe use <C-CR> for append instead, and the usual <S-CR> for a newline?
5. I'm kind of nervous to clear buftype? Not certain what unintended behaviors that may enable/disable. Although it'd allow the completion LSP to auto-attach, a nice bonus.

How would you feel about adapting snacks.input to be multi-line per above? I know the dependency isn't great but I also would really prefer not to maintain a separate configuration. And I think it's cool if the existing snacks.input "just works" as multiline when you realize your prompt is turning out pretty long. Rather than having to think ahead of time, "do I want to use vim.ui.input or the larger floating window for this prompt (or globally)?"

[janorga]

Question about this issue scenario:

I am currently using opencode neovim plugin with snacks: Should <S-CR> append things in the box, but it is not working beacuse of snacks? That is the issue?
In my case, asking in the pop-up and pressing Shift+CR just sends the ask to opencode; I don't notice anything about "append".

[nickjvandyke]

@janorga it should append your input (and a newline) to opencode's prompt input field, without submitting the prompt

[janorga]

Then I suppose it behaves buggy in my case 😭

[nickjvandyke]

Sorry haha to clarify - it is supposed to send the prompt to opencode, just without submitting it. It's expected that the ask input disappears.

[janorga]

In my case, <S-CR> and <CR> behave exactly the same, ask input dissappears and both instant-submit the prompt to opencode.

[janorga]

@nickjvandyke probably I've found the issue, in my case, modifying the keymap from <S-CR> to <C-J> (for example) does the job.

Doing an investigation through AI the following is obtained:

---

In terminals without advanced keyboard protocol support (xterm-256color in tmux),
<S-CR> and <CR> produce the same byte sequence (0x0d), making them indistinguishable
to Neovim. Use <C-J> (0x0a) instead, which is a distinct byte sequence that all
terminals can differentiate.

To enable <S-CR> support, use a terminal with keyboard protocol support:

• Kitty
• WezTerm
• Ghostty
• Alacritty (recent versions)

---

Could you check if this issue makes sense to you? If that is the case, could changing to anything else compatible be considered?

[duguyue100]

@nickjvandyke Thanks for the encouragement, and happy to see there is an engagement on this!

To be honest, I don't find the cursor following feature by snacks.input that useful. I would rather have a box that is centered in the screen, sort of how 99 does it: https://github.com/ThePrimeagen/99