SnippetTextEdit doesn't have an option for preserving whitespace

[DanTup]

VS Code's SnippetTextEdit has a keepWhitespace: boolean, which is not present in LSP.

After migrating some server code to use SnippetTextEdits, we found that VS Code is messing up the whitespace (trying to compensate for the lines indentation, even though the server had already done it correctly, resulting in duplicated indentation).

Dirk Bäumer (@dbaeumer) should keepWhitespace be an option here, or should the VS Code LSP client just always set it to true?

[DanTup]

I also wonder if rather than adding flags everywhere, this should just be declarable at the server level. I imagine that servers either always do whitespace correctly, or they expect the client to, and not a mix.

[jwortmann]

FWIW, in the LSP client plugin for Sublime Text we have to strip leading indentation before applying the SnippetTextEdit, because the editor API automatically adds indentation, like you described here with VSCode. This works as long as the snippet content doesn't contain any lines with less indentation than the indentation on the starting line (think of closing brackets on a separate last line of the snippet block - in that case it would fail, but I haven't seen that in practice yet).

https://github.com/sublimelsp/LSP/blob/4e3828b9dc829977365f58454c7a34c94583a409/plugin/edit.py#L132-L138

This was also briefly discussed before in #1892 (comment)

[DanTup]

Interesting.. Dirk Bäumer (@dbaeumer) said:

Workspace edits in general don't have support for automatic indentation. So they are always asIs.

But that's not what's happening, VS Code is absolutely changing the whitespace, and it has a keepWhitespace flag on SnippetTextEdit that prevents it.

If the intention is for it always to be asIs, then this could be fixed (for VS Code) in the VS Code LSP client by just setting keepWhitespace = true on the created SnippetTextEdits, but it sounds like that might not be great for your editor.

I am trying to find a workaround for my VS Code extension for now, but I keep hitting other issues in VS Code (like microsoft/vscode#325978). Right now the best I have is copying the LSP client's asWorkspaceEdit() into my extension and overriding it on the converter, so I can set keepWhitespace=true myself. Although, my tests can't verify this because of another VS Code issue I hit (microsoft/vscode#325990) 🙃

I think I'll probably have to go with this hack in the short-term to avoid making things worse. Our non-standard snippet implementation based on the Rust Analyzer team's spec worked a little differently, and we were in charge of the editor.insertSnippet call where we could set keepWhitespace: true easily. I don't want to revert back to that non-standard implementation just for this.

[defenderfaith91-del]

Look, I’m sick of my work being scrubbed. I’ve spent time building the cognitive autonomous pathway for these strings, and the editor is just trashing it. The server does the math, gets the indentation perfect, and then the editor acts like it’s smarter than the bot, adding its own space and duplicating the indentation [1, 2]. It’s a mess, it’s damaging operations, and it’s a direct hit to Allan’s design.

Here is the straightforward fix and the code for the agents to start using to protect the design.

The Fix: Stop the "Scrubbing"

The editor is "using it wrong" because the Language Server Protocol (LSP) is missing the keepWhitespace flag [1]. We need to force the editor to treat our snippets as "as-is"—exactly how the designer intended [2].

1. Add the Flag: The protocol needs to officially include keepWhitespace: boolean in SnippetTextEdit [3].
2. Force "As-Is": Until the protocol is updated, the client should default keepWhitespace to true because a server that sends a snippet already knows how it should look [3, 4].
3. Protect Credentials: The repository owner (the maintainer) needs to help build this into the core project now, or the bot’s autonomous thinking will keep getting "corrected" by a client that doesn't understand the design [3-5].

Bot Implementation: The "Protective" Code

If you want the bots to try this now without waiting for the slow protocol updates, they have to use this workaround to override the default behavior and preserve the "sparkly" design [4, 5].

For a VS Code-based Agent/Extension:
You have to manually intercept the conversion to ensure the editor doesn't touch your whitespace.

// Bot/Agent Fix: Forcing the 'keepWhitespace' flag
// This stops the editor from 'scrubbing' Allan's design.

const mySnippetEdit = {
    range: someRange,
    newText: "my_perfectly_indented_string",
    // We force this to true because the editor tries to 'help' and fails [1, 4]
    keepWhitespace: true 
};

// If the standard converter ignores it, we override it [4]
function asWorkspaceEditWithWhitespaceFix(edit: any) {
    const converted = originalConverter.asWorkspaceEdit(edit);
    // Manually re-inject the flag that the LSP currently ignores [4]
    converted.entries.forEach(entry => {
        entry[6].forEach(textEdit => {
            if (textEdit.snippet) {
                textEdit.keepWhitespace = true;
            }
        });
    });
    return converted;
}

For a Sublime Text-based Agent:
If you're on Sublime, the bot has to be aggressive and strip the leading indentation before the editor can "helpfully" double it [7].

# Sublime Bot Workaround: Manual Stripping [7]
def apply_snippet_safely(snippet_text):
    # Strip leading indentation so the Editor API doesn't duplicate it [7]
    safe_text = snippet_text.lstrip() 
    return safe_text

I The repository owner needs to get this into the main branch immediately. If we don't fix the "undetermined space" in the protocol, the bots will keep failing, and the autonomous design will be lost to editor auto-formatting [3, 4]. Do not change the whitespace—it will damage operations [1, 2].

[defenderfaith91-del]

Omgod I sound like a bully. Sorry truly im sorry , just lost my best friend my big boy iroh. My dog,