Clojurians Log v2

It can, if they're in a subdirectory of the main repo. I'm still figuring out how that support works.

If the paths are unique then you should be able to share a connect sequence for several connections.

It doesn't prompt for a path when I use Calva to launch a REPL

If I try to jack in a second time, it shuts down the existing REPL first

Maybe VS Code somehow presents it as one filesystem… Do you see the worktree as a subdirectory in the file explorer?

Yes, it's just one file tree. I have my worktrees in an ignored worktrees directory in my project. This is more or less the pattern I've seen harnesses built for worktree workflows use, e.g., https://code.claude.com/docs/en/worktrees .claude/worktrees.

I’ll have a look at what can be done. What does “ignored” mean here? .gitignore ?

Yes

I also exclude it from search indexing so I don't see lots of copies of the ~same code show up

> I also exclude it from search indexing That may be what hides it for Calva.

See what happens if you don’t.

It probably isn’t search exclude…

But the gitignore can cause it if you have search.experimental.useIgnoreFilesInFindFiles on.

Confirmed. Excluding it via files.exclude causes Calva to skip root selection. Excluding it via search.exclude does not.

Ah, and files.exclude too.

This does still leave me manually setting up a REPL for each agent and then telling it which REPL to use. A tool to launch a REPL (maybe guarded so it will not kill existing REPLs) would be useful for this workflow.

Please file an issue about the original problem, which would be launching repls from in-workspace worktrees and excluded directories.

Meanwhile you can ask the agent to use joyride to jack-in itself.

The original problem is a non-issue, isn't it? It was misconfiguration on my end — I shouldn't have excluded it in files.exclude unless I wanted all tooling to ignore that path.

I thought you didn’t want to relax files.exclude. So what does “manually setting up a REPL” mean then?

> A tool to launch a REPL (maybe guarded so it will not kill existing REPLs) would be useful for this workflow. That’s Joyride, I would say.

> I thought you didn’t want to relax files.exclude. So what does “manually setting up a REPL” mean then? Well... bit of an XY problem. The original aim is: I want agents to be able to work in isolated worktrees within the same window, each with a REPL rooted in that worktree. Tracing my steps on why I set the exclude options the way I did, it looks like I was trying to exclude worktrees from the References Code Lens — and it didn't work. So, a tangential feature request: Allow paths to be excluded from Calva's implementation of the References Code Lens. Tested with Joyride. The agent was able to start a REPL at a worktree root even when it is hidden from the GUI selector by files.exclude. So I have a viable way forward with the original aim, thanks!

> So, a tangential feature request: Allow paths to be excluded from Calva’s implementation of the References Code Lens. This is clojure-lsp functionality and the exclude option may already exist. If it doesn’t best brought up on clojure-lsp.

Somewhat related. I don’t use worktrees so don’t know what people prefer, but I think I would prefer keeping it outside the project. So then what I would do (which I do anyway most often) is to use a VS Code workspace. Then add worktrees as folders to the workspace. This may also stop clojure-lsp from including them in the references.

Never worked with the workspace concept, maybe I'll try that. I know worktrees are commonly done as subdirs under the main project, but I frankly don't know why. Still tinkering with workflows.

I think with many harnesses workspaces are not an option for the worktrees. But regardless where you end up storing those, workspaces are super useful. One use case for me is that I can show the agent other projects on my computer, without allowing it to roam around freely. I just add the project I want it to see as a workspace folder. Also great when working with someone else’s project, where I am not free to add my tasks, scripts, skills, etcetera. I can create a dev project for it, make it the root/first folder of a workspace, and then add the project I want to work with, keeping my personal stuff in the dev project. Note that when making a regular VS Code window into a workspace, VS Code will restart the extension host. It will do so without warning.