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-J> for append instead (same as opencode default), 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. prompt buffer supports multiline input neovim/neovim#32420 may help

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

[nickjvandyke]

@duguyue100 yeah I agree, if we "expand" snacks.input like this, we'd want to disable the cursor-following somehow.

I would prefer to start with extending snacks.input to continue using vim.ui.input under the hood for consistency. From my perspective as a user, I dislike when plugins each have their own, slightly different, windows and input methods. An experience that "just works" and fits what users expect (i.e. are used to) is a top priority 🙂

I kind of assumed that people tend to write short prompts in ask anyway? And use the opencode TUI for longer stuff. But I could definitely be wrong about that.

[nickjvandyke]

@janorga thanks for doing that research! That is disappointing. To clarify, you are using one of those terminal apps, but tmux being in the path is the issue?

I'm open to other intuitive keymaps! I chose <S-CR> because it's pretty standard for inserting a newline (rather than submitting) in text editors, and it feels intuitive to modify the default submit key. But after you mentioned <C-j>, it seems that is somewhat standard too! Including in opencode itself.

[janorga]

@janorga thanks for doing that research! That is disappointing. To clarify, you are using one of those terminal apps, but tmux being in the path is the issue?

I'm open to other intuitive keymaps! I chose <S-CR> because it's pretty standard for inserting a newline (rather than submitting) in text editors, and it feels intuitive to modify the default submit key. But after you mentioned <C-j>, it seems that is somewhat standard too! Including in opencode itself.

I am using just ssh with tmux+zsh in my VM. I'd bet now that opencode uses <C-J> for interoperabilty, despite being counterintuitive at first glance.

If you want, I can even go for a PR where "append keymap" is configured by plugin options by the end user, being <S-CR> the default value.

[duguyue100]

@nickjvandyke

An experience that "just works" and fits what users expect (i.e. are used to) is a top priority 🙂

Yep, I think out-of-the-box experience would be very nice, no argument there.

I kind of assumed that people tend to write short prompts in ask anyway? And use the opencode TUI for longer stuff. But I could definitely be wrong about that.

Just to share my workflow, what I often do is that I use visual mode to highlight exactly the part I want OpenCode to look at and then describe a feature I want it to implement.

• If it's a small enough task, I might just solve it myself; having an agent is not so much faster.
• I occasionally ask things like "explain this code to me", but very rarely.
• For 80% of the time, I would actually take one minute to offload my exact thinking and the approach that I would like it to take in the input box, and then review the changes myself.
  Therefore, in my case, a prompt box that does not move or resize itself in width consistently would be super nice.

If I may propose an alternative, it could be just another prompt command like ask but suited for longer prompts (with a centered float window, etc). Then user can choose to use either one. And I can just remap my bindings to use it like an "ask".

[duguyue100]

Man, I'm feeling a bit obsessed on this, so I ended up vibe-coding the feature. Certainly, it's not really production grade, but it does the trick. And luckily, all the @ references would still work without a problem.

As you can see, I have a somewhat quirky setup. I don't like the idea of sacrificing my neovim real estate so I put opencode to bottom right, if I want to view the conversation, I go there and use tmux's zoom.

Anyway, this is the screenshot, and this is just to give people an idea what it might look like.