auto-run `ucm` sometimes starts in wrong directory

[sellout]

When ucm is auto-run by the extension, it doesn’t run from the directory of the file that triggered ucm, resulting in commands like edit writing to the wrong location.

replication

1. Open a non-Unison workspace in VS Code.
2. Make sure the Unison extension has unison.automaticallyOpenUCM set to true.
3. Open or create a scratch.u file in a different directory.

At this point, ucm should auto-run in a terminal. However, it runs from the directory of the non-Unison workspace. And so edit, etc. will not use the scratch file you opened, but create a new one elsewhere.

notes

If you open VS Code without a workspace, or in a workspace with an existing scratch.u that you are using, it works fine, because the terminal will start in the expected directory, but there are cases where the terminal’s directory doesn’t match the directory we’d like ucm to run from.

solution

Change the launch command from ucm to cd "$(dirname FILE)"; ucm (or use && instead of ; – not sure what the best behavior is if the cd fails somehow).

Alternatively, we could add an option like --scratch-file /path/to/scratch.u or --watch-dir /path/to/to ucm and have the launch command be ucm --watch-dir "$(dirname FILE)". I like this option because it makes ucm more independent of its run context, but it does require more work.

[aryairani]

Hmm, I've always just assumed that VS Code runs stuff in the directory it was opened from. Does it run it from the directory of the workspace?

What should we do if the user opens two scratch files in different non-Unison-workspace directories, where we can only have one shared LSP instance, is that right?

[sellout]

I think two-scratch-files is a separate issue. This is just about the situation when ucm first starts. Once you are interacting with a running ucm, then opening things in different directories is just a run-of-the-mill ucm issue.

In this case, it’s like you open a scratch file, ucm automatically starts, you type some stuff, save the file, nothing happens. It feels like intuitively the file that triggers ucm to start should be treated as a scratch file by that ucm.

I think the issue is that if there is an active workspace, you can open a file from anywhere on disk (i.e., outside of the workspace), but the default dir will still be the workspace dir. If there‘s no workspace, it’ll default to the file’s directory (so ucm works in that case).

[ChrisPenner]

Hrmm, yeah with both this and the MCP the tools definitely prefer to spawn a CLI process per workspace and communicate via STDIN/STDOUT; rather than having "one global LSP" or "one global MCP".

I've avoided this so far because of codebase locks and duplicated memory, but it's worth reconsidering that approach.