Removed invalid 'clear' from Runner

[JakubSchwenkbeck]

Motivation

Removed the invalid call of clear for the terminal when running a Effekt-file via the extension
Resolves #41

Changes

• removed invalid sendText("clear"), which caused an error as clear is not a valid windows command
• added a VSCode API call executeCommand('workbench.action.terminal.clear'), which should perform the clear operation platform independent

[jiribenes]

I'm confused as to how this works -- how does VSCode know which terminal to use?
Does this work on your machine? 🤔 Can we test this on a normal windows cmd terminal that doesn't support clear?

[JakubSchwenkbeck]

Oh, did I mix up the terminal the problem occurs in? Are we talking about the integrated terminal which runs inside VScode?

[JakubSchwenkbeck]

This API-call works for the integrated terminal, platform independent.
As I read in extension.ts#L1343, the [currently] "active instance" is cleared.

I think this is nicer than something like :

const clearCommand = process.platform === "win32" ? "cls" : "clear";
terminal.sendText(clearCommand);   

[jiribenes]

Probably, but it would really need to be tested. Though even for an external terminal, I'd still love to know how VSCode itself can clear a terminal (since I think it's able to do so)... and hopefully they do have some API for such an action too?

[JakubSchwenkbeck]

Good question, which I don't have any answer for currently 🤔

[JakubSchwenkbeck]

Yes, I looked into the codebase for a few minutes and moved several clearBuffer()calls down in the abstraction level, but haven't found an ending yet. By time, I'm happy to investigate further:)

[JakubSchwenkbeck]

The ITerminalInstance itself uses two .clearBuffer() https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L1341
=> XTerm and a _process, one of them should hold the actual commands...

[jiribenes]

Yep, but I think that's not necessarily the level we'll be able to reach (since that API is most likely private [?]), that's managing the terminal interface via xterm.js, I'd assume.
Instead, I think we need to search "up" now to see what we can use in the public API that in turn triggers the .clearBuffer().

[JakubSchwenkbeck]

I can't find a way to use the public API to call .clearBuffer(). There doesn’t seem to be a way to explicitly set which terminal is active (might be worth raising an issue in the VS Code repo?). The workaround of using terminal.show() does update onDidChangeActiveTerminal, but the activeInstance used in the API call doesn’t update immediately, which causes unexpected behavior.

[JakubSchwenkbeck]

Maybe VScode Issue #2238507 will gather us more helpful information :)

[JakubSchwenkbeck]

I recommend sticking with terminal.show() for now. While it might not cover every use case, it keeps terminal actions explicit and user-driven, which is important for both security and reliability.

from microsoft/vscode#238507 (comment)

[JakubSchwenkbeck]

This solution would suggest using terminal.show() to move focus to the EffektRunner terminal and then using the API await vscode.commands.executeCommand('workbench.action.terminal.clear');. When tested, I experienced that there needs to be some sort of sleep to ensure the activeInstance is updated. This feels wrong as a solution.

Edit: It doesn't seem reliable at all after some testing - even with the sleep.

[JakubSchwenkbeck]

I also recommend using Terminal.show(), but then polling the state of activeTerminal for a short period to see when it changes. I expect this should be fairly reliable.

Well it's again this variant, I can look into a viable solution with terminal.show() if we decide against the simple ternary ?