rawLog option for OutputChannel to colourise the Ark log

[lionel-]

I would like to have colourised output in our Ark log because it is currently hard to read. VS Code doesn't support ansi escapes in output channels (see wontfix issue microsoft/vscode#571) but it does colourise output channels that are created with log: true.

We can't do the latter option however because that automatically adds timestamps (which we already add elsewhere) and misleading [info] tags. I found a way to prevent VS Code from adding these with a new option. Using this, the Ark output becomes much more readable:

Screen.Recording.2023-10-16.at.15.18.50.mov

However this requires changing a bunch of VS Code signatures to thread the option in. Is this too much @jmcphers?

[jmcphers]

We should avoid modifying the VS Code API definitions. If it's Positron-specific, it should go in positron.d.ts. For this case I think we could make a scoped API, something like createLogChannel (i.e. rather than creating a superset of VS Code's API, we create an API whose use doesn't overlap with createOutputChannel).

It's okay to co-opt VS Code's internals to plumb additional flags although there's some tension between DRY vs. not wanting to create a lot of opportunities for merge conflicts.

[lionel-]

I made these two changes:

• A new createRawLogOutputChannel() function is created in vscode.window but not publicised to the API file. I created it in the vscode namespace rather than positron because we don't have access to extHostOutputService from the latter namespace. Since it's hidden, using it requires a @ts-ignore tag, which I thought is ok here.

• I changed the approach to use more wrapping of classes and injected methods to avoid changing existing code. This should make merging easy.

[jmcphers]

I created it in the vscode namespace rather than positron because we don't have access to extHostOutputService from the latter namespace

We do! I punched a little hole for exactly this use case and we use it in a couple places already. Here's the relevant bit:

positron/src/vs/workbench/api/common/positron/extHost.positron.api.impl.ts

Lines 38 to 51 in 332865e

	// Retrieve the raw `ExtHostWebViews` object from the rpcProtocol; this
	// object is needed to create webviews, and was previously created in
	// `createApiFactoryAndRegisterActors` when VS Code's API factory was
	// created earlier.
	//
	// The `getRaw` method is a Positron extension to the `rpcProtocol` that
	// allows us to retrieve the raw actor object so that the Positron API and
	// VS Code API can share a single instance of `ExtHostWebViews`, which is
	// necessary since the instance effectively needs to be a singleton.
	const extHostWebviews: ExtHostWebviews = rpcProtocol.getRaw(ExtHostContext.ExtHostWebviews);
	if (!extHostWebviews) {
	throw new Error('Could not retrieve ExtHostWebviews from the RPC protocol. ' +
	' The VS Code API must be created before the Positron API.');
	}

So you can add a getRaw accessor, which will allow you to add this as an exposed Positron API instead of a hidden VS Code API (and should also eliminate the need for ts-ignore).

[lionel-]

oh neat, I've now moved the function to the positron namespace

[lionel-]

Since getRaw() already throws, I've removed this error and merged the extra message info in the upstream error. This way we don't have too much redundant error handling in all the getRaw() calls.

[jmcphers]

That's nicer, thanks!

[jmcphers]

LGTM!