R: After a debug session commands like n or s should be omitted from the history

[lionel-]

Brought up in https://github.com/posit-dev/positron-beta/discussions/148.

On the one hand, as these commands are only used to advance or step in, they don't correspond to real expressions that you can use outside of debugging sessions. On the other hand, users might use the up arrow to enter a command multiple times.

RStudio takes care of both considerations and discards the commands after the debug session stops.

[DavisVaughan]

If it was easier to implement, I would not mind if we just never recorded history for n, s, c, Q, etc in the history cache

I don't think I've ever done up to re-request n 😆

[lionel-]

I think the hard part is to implement custom behaviour during debug sessions (since we do need to record n etc outside of debug sessions), rather than what behaviour to implement.

[lionel-]

Duplicate of #4478

[lionel-]

As pointed out by @thomasp85, not quite a duplicate!

[lionel-]

I would not mind if we just never recorded history for n, s, c, Q, etc in the history cache

In stats scripts there's lots of one-letter variables. I think users would wonder why they can't use Up to print a variable again.

[DavisVaughan]

When ark sends Positron a command to execute (n, c, etc), it goes through this execute() call that we control completely:

positron/extensions/jupyter-adapter/src/LanguageRuntimeAdapter.ts

Lines 1019 to 1029 in fc1fdd3

	// If the DAP has commands to execute, such as "n", "f", or "Q",
	// it sends events to let us do it from here.
	case 'execute': {
	this.execute(
	msg.content.command,
	uuidv4(),
	positron.RuntimeCodeExecutionMode.Interactive,
	positron.RuntimeErrorBehavior.Stop
	);
	break;
	}

I wonder if we can extend this to include record_in_history: false that we can set here? That seems like it might solve this part well

[DavisVaughan]

Oh interesting, the execute() command already kind of handles this internally. By setting positron.RuntimeCodeExecutionMode.Interactive we are requesting that store_history = true on the server side.

positron/extensions/positron-supervisor/src/KallichoreSession.ts

Line 508 in fc1fdd3

store_history: mode === positron.RuntimeCodeExecutionMode.Interactive,

But even if we set RuntimeCodeExecutionMode.Transient I don't think that would help. It would help the server not store the debug command in its history, but the client (Positron) isn't really respecting that in any way.

From what I can tell, Positron waits to receive an IOPub::ExecuteInput response back from the server before displaying anything in the console or recording anything in history, and that message type doesn't relay any information about whether or not the message should be stored in history

export interface JupyterExecuteInput extends JupyterMessageSpec {
	/** The code to be executed */
	code: string;

	/** The count of executions */
	execution_count: number;  // eslint-disable-line
}

It almost feels like Positron should be recording some kind of information about store_history when it sends out an ExecuteRequest, so it can react appropriately when getting the rebroadcast ExecuteInput from the server.