Question regarding TextDocument.update(...) from 'vscode-languageserver-textdocument'

[goto40]

Background:

• We had issues with flickering formatter results (when repeatedly reformatting a document), caused by bugs in our formatter.
• We have build a test case to format documents multiple times to assure that we do not re-introduce flickering effects

We have a test case where we want to apply TextEdit[]s to a Langium Document.

We use TextDocument.update(langiumDoc.textDocument, [{text: newFormattedText}],0) in order to update the document after applying edits from our formatter (like here).

So far it seems ok in the first place (the text has changed). But when we re-run our formatter on the updated document, we get strange effects (different to interactive tests in vscode, when we reformat a document). We have the feeling that we need to trigger a reparse or something similar after calling TextDocument.update(...).

Are we on the right track? How do we "finalize" formatting a document in memory (for our test case)?

[msujew]

Hey @goto40,

FYI, the formatting can "fixed" by simply returning true here (see also #1550):

langium/packages/langium/src/lsp/formatter.ts

Lines 203 to 206 in 4bbc180

	protected isNecessary(edit: TextEdit, document: TextDocument): boolean {
	const existing = document.getText(edit.range);
	return existing !== edit.newText;
	}

For your actual question: Langium only runs a document through the document builder in two cases:

1. We received a textDocument/* notification from the language client (handled by the LanguageServer implementation, this is what is done when running in VS Code).
2. You perform a DocumentBuilder#update call manually on the adjusted document. The Langium lifecycle always needs to be run explicitly and will never run implicitly.

[goto40]

Thank you for the quick reply!

We tried out to call Document.builder.update([doc.uri],[]) after updating the doc.textDocument:

• doc is in original state
• then we format the document (TextDocument.applyEdits...)
  • the result is a string with the expected formatted model
• TextDocument.update(langiumDoc.textDocument, [{text: newFormattedText}],0); update document with formatted version (ok)
  • we checked that doc.textDocument.getText() is as expected now (changed; formatted version)
• Document.builder.update([doc.uri],[])
  • now we have the original text (prior to any modification = "original state" above) - we expected the modified version to be present here

Question:

• Is Document.builder.update([doc.uri],[]) reading from file instead of using the modified in-memory representation (here we have langium 2.x)?
• Is Document.builder.update([doc.uri],[]) using the doc.textDocument we updated with .TextDocument.update?

[msujew]

Is Document.builder.update([doc.uri],[]) reading from file instead of using the modified in-memory representation (here we have langium 2.x)?

Is Document.builder.update([doc.uri],[]) using the doc.textDocument we updated with .TextDocument.update?

Both of these depend on whether the textDocument is registered with the TextDocuments service. See:

langium/packages/langium/src/workspace/documents.ts

Lines 270 to 272 in 7374f07

	const oldText = document.parseResult.value.$cstNode?.root.fullText;
	const textDocument = this.textDocuments?.get(document.uri.toString());
	const text = textDocument ? textDocument.getText() : await this.fileSystemProvider.readFile(document.uri);

Note that the API doesn't allow to actually update the text document, you need a workaround, see:

langium/packages/langium/src/test/langium-test.ts

Lines 705 to 713 in 7374f07

	export function setTextDocument(services: LangiumServices | LangiumSharedLSPServices, document: TextDocument): Disposable {
	const shared = 'shared' in services ? services.shared : services;
	// eslint-disable-next-line @typescript-eslint/no-explicit-any
	const textDocuments = shared.workspace.TextDocuments as any;
	textDocuments._syncedDocuments.set(document.uri, document);
	return Disposable.create(() => {
	textDocuments._syncedDocuments.delete(document.uri);
	});
	}

[goto40]

@msujew you reply speed is incredible fast!! Thank you so much :-)

The proposed workflow looks very complicated. I think we might workaround by saving the modified texts and reloading them into a new workspace (that is what we did before). We will give it a second try and then maybe fallback.

This is no issue, since we are just testing some details here (it is no end-user functionality)

Thank you!!