forgot to push the padding changes - here's what it looks like on multiple lines now:

What do keybinds look like, now that the search bars are multi-line? Does enter still submit the search like before?

#50420 was just added to the macOS default keymap to support typing newlines with ctrl-enter.

What do keybinds look like, now that the search bars are multi-line? Does enter still submit the search like before?

By default in this - up and down still moves between history items, enter and shift+enter moves to the next and previous result, respectively, and ctrl+enter for newlines.

up and down still moves between history items

VS Code handles this by letting the up/down arrow keys manipulate the cursor, but if the cursor is on the first line and you press up arrow (or if the cursor is on the last line and you press down arrow), then it moves to the adjacent history item. Worth considering here.

ctrl+enter for newline

Does the ctrl-enter keybind from the Editor && mode == auto_height context apply to the search bars now? If so, then the keybinds added in #50420 can be removed.

up and down still moves between history items

VS Code handles this by letting the up/down arrow keys manipulate the cursor, but if the cursor is on the first line and you press up arrow (or if the cursor is on the last line and you press down arrow), then it moves to the adjacent history item. Worth considering here.

right! if it wasn't clear in my response, it does this by checking explicitly whether you are at the beginning of the first line or the end of the search input - I also tried to show this in the video but since there's no key inputs shown it's all kind of a mess.

Does the ctrl-enter keybind from the Editor && mode == auto_height context apply to the search bars now? If so, then the keybinds added in #50420 can be removed.

It does. If my comment here is addressed and this PR stays, I'll modify accordingly :)

Thanks for working on this, @claiwe! Multi-line search is a great addition. @gaauwe and I tested it out and pushed a couple of follow-up commits addressing some edge cases we ran into:

Fix search history navigation and arrow key behavior (17737a56e7)

• Pressing ↓ past the last history entry was clearing the search box. This was a pre-existing issue, but we decided to fix it here since we want ↑/↓ to feel more intuitive now that the search input supports multiple lines. It now preserves the current text instead of clearing it.
• In project search, unsubmitted query text is saved as a "draft" before navigating history with ↑, and restored when you press ↓ past the end. This way you don't lose what you were typing.
• Moved the multi-line arrow key logic from keybinding contexts into the action handlers themselves. For single-line content, ↑/↓ always navigate history. For multi-line content, ↑ only navigates history when the cursor is at offset 0, and ↓ only when the cursor is at the end — otherwise they move the cursor normally within the text. This simplified the keybindings back to unconditional up/down mappings.

Scroll cursor into view for long history entries (2f8c913d4e)

• When navigating to a history entry that exceeds the editor's max visible height, the cursor wasn't scrolled into view. Added request_autoscroll after setting the text in both buffer search and project search.