Fish autosuggestions recover whole multiline commands
Fish 4.2 extends history suggestions beyond individual lines and repairs the rendering around multiline prompts. UTF-8 and embedded data also become defaults.
A multiline command in history contains relationships that disappear when the shell suggests one line at a time. An opening for belongs with its body and closing end. Recovering an isolated body line can be useful, but it does not recover the operation the user previously entered. Fish 4.2.0, released November 10, changes history autosuggestions to include multiline commands.
The release notes put that change first. It extends work in 4.1, which enabled suggestions within multiline input and could suggest individual lines taken from multiline history entries. The distinction is between the current editing buffer and the suggested history item. Supporting several lines in the former did not automatically preserve several lines in the latter.
I regard autosuggestions as one of fish's strongest reasons to exist as a personal shell. They let previous work inform the command being entered without a separate search interaction. Preserving a complete block makes that relationship more useful for commands that were deliberately written across several lines.
Whole-command matching precedes line matching
The 4.2 reader implementation makes the search order explicit. It first performs a prefix search using the entire command line. It then considers a line-prefix search using the line containing the cursor. For a whole-item match, the candidate is the history entry itself. For a line match, the code splits the history item and selects a matching constituent line.
That order preserves both behaviors. A prefix can recover a complete multiline operation, while a current line can still benefit from a useful line inside another history entry. The line-search path also checks whether the cursor's line contains the start of the relevant process before using it. The implementation therefore distinguishes an independent line from text that merely continues a process begun elsewhere.
Consider a previously executed block such as this one. It uses fish's ordinary multiline syntax, with an explicit closing end.
for item in alpha beta
printf '%s\n' $item
end
The change allows history autosuggestions to recover that complete form when a matching prefix is entered. It does not require flattening the block into a single physical line. The exact offered item still depends on history and matching, so this is an example of the newly supported shape rather than a guarantee that every for prefix selects this block.
A suggestion remains editable input
The interactive documentation shipped with 4.2 describes the existing acceptance model. Right arrow or Control-F accepts an autosuggestion, while Alt-F accepts its first suggested word. Ignoring the displayed suggestion leaves it unexecuted. Acceptance inserts text into the command line, where it can be inspected and changed.
Multiline editing already supports entering a newline while a block remains open. Alt-Enter can also insert a newline into a command that is otherwise complete. A whole history suggestion therefore joins an established editing model. The new behavior does not introduce a separate executable history object or an alternative block syntax.
The distinction between acceptance and execution becomes more visible when a suggestion includes several commands. A single prefix may now display an entire body. That is valuable when recalling an operation whose internal arguments have faded from memory. It also means the content to inspect includes the remaining lines, rather than only the suffix on the cursor's row.
Rendering the part that fits
The project's multiline autosuggestion test exercises the screen consequences. It records a multiline block, requests a suggestion, and checks the displayed output at different terminal heights. The expected output truncates suggestions when necessary, with an ellipsis indicating that more text follows.
The test also checks that pressing Enter within an unfinished block preserves the suggestion and that a suggestion can be computed after that newline. Other cases combine a multiline prompt with a small terminal window. These cases matter because the proposed text occupies screen space before the user has accepted it.
A suggestion can be longer than the available display without being a different history entry. Screen clipping must not change the distinction between typed content and proposed content. The tests check that suggestion rendering does not push the prompt upward merely to show the rest. In a narrow window, wrapping introduces another limit on how much can be displayed.
I prefer this extension to a workflow that requires remembering which history-search mode retrieves an entire block. The existing suggestion interface can keep the command's structure intact. Its display still has to respect the amount of terminal space available for reviewing it.
Prompts also change height
Fish 4.2 repairs another multiline transition introduced by transient prompts. Issue 11875 demonstrates a two-line editing prompt whose final rendering occupies one line. In 4.1.1, portions of the old display could survive the replacement. Different prompt widths and completion interactions changed the visible corruption.
The prompt function documentation specifies fish_transient_prompt and the --final-rendering argument used before execution. The final form can omit contextual lines that were useful during editing. Correct replacement consequently requires clearing the rows belonging to the previous form. The release repairs the case where the initial prompt is taller than its final rendering.
This complements multiline suggestions because both require accounting for text that disappears. A renderer cannot derive the cleanup region solely from the new output. It must also account for what previously occupied the terminal.
Encoding and bundled helpers become explicit defaults
The versioned changelog records two other default changes. Fish now assumes UTF-8 even when the system lacks a UTF-8 locale. Invalid UTF-8 bytes still round-trip, including filenames using older encodings, although their command-line rendering can differ. The former ASCII replacement behavior on systems without a multibyte locale also goes away.
Separately, standalone build mode becomes the default. Internal data is embedded, so an upgraded installation's changed helper functions will no longer break a running shell that uses its own embedded versions. The release still installs redundant data files to protect shells started before this change. This addresses a version-coordination problem between a running executable and its installed support files.
The 4.2 build documentation still distinguishes a full installation's documentation and package integration from a movable Cargo-built binary. Embedded support data does not remove those packaging concerns. It gives the shell a consistent copy of its internal functions while retaining separate mechanisms for documentation and third-party integration.