Our formatter currently returns a single big edit of the entire document, which originally resulted in selections, breakpoints (etc.) going bad during a format. The formatter does support tracking a single selection location, but VS Code doesn't expose this on the basis that it wouldn't solve the multi-cursor scenario, nor things like breakpoints. Their recommendation is to compute more minmal edits. Still, VS Code added code to compute minimal edits automatically when formatters did give it a single edit, however imposed a limit of 10k characters to the file (in which case it just skips the computation).

This means that for files over 10k, those bad things still happen. I've asked if VS Code will consider increasing the limit, but I think it's unlikely and even so it'll only move the boundary rather than solve it.

We may wish to just implement the minimal edit computation ourselves with no limit. Whether we should do that in the extension, or the server (or dart_style), I'm not sure. If done in the server or dart_style, it'd probably need to be opt-in as there may be tools assuming only one edit will be returned.

@bwilkerson we did talk about this > 2 years ago when it first came up, but the VS Code solution seemed to resolve it (I didn't realise it had a 10k limit at the time, which seems quite low IMO, especially for Flutter code).

@devoncarew @pq out of interest, do you know how IntelliJ/AS are preserving things like breakpoints during their formats?