Wrong path 'Go to Definition' when working in a Docker container

[maxweber]

First of all, thanks a lot for creating Calva, it is awesome 🎉

We develop our project inside a Docker container, so that all developers have the same dev environment. While VSCode runs on the docker host. In our case the source code resides inside the /app/ folder within the Docker container. When we use right-click -> 'Go to Definition' we get the error shown in the screenshot. It uses the path from within the container, which does not exist on the Docker host. One way to fix this might be to use the relative path to the source file and always prepend the path of the current VSCode project (which should be a path on the Docker host).

[PEZ]

Hi! Thanks for reporting. Can you try with latest nrepl and cider-nrepl and see if the issue persists (I think it will, but for good measure). If you are using Jack-in, these settings should do it:

  "calva.jackInDependencyVersions": {
    "nrepl": "1.3.0",
    "cider-nrepl": "0.51.0",
    "cider/piggieback": "0.5.3"
  },

Also, if you enable nrepl logging, via the command Calva Diagnostics: Toggle nREPL Logging Enabled, we can see if the nrepl server may already be trying to help Calva with the issue.

There is also a calva.definitionProviderPriority option that defaults to:

  "calva.definitionProviderPriority": [
    "repl",
    "lsp"
  ],

I think that clojure-lsp will be using the local file paths, so you can hopefully use that as a workaround while we figure out how to make the REPL provider do the right thing.

[maxweber]

Thanks a lot for the workaround. As suggested I set calva.definitionProviderPriority to:

"calva.definitionProviderPriority": [
  "lsp",
  "repl"
]

and now 'Go to Definition' works 🥳

One strange thing was that the settings in the UI always switches back to the default, despite the fact that you get the correct one if you use 'Copy Settings as JSON'. Maybe a Cursor-only issue:

I also looked at the Calva Diagnostics: Toggle nREPL Logging Enabled outputs and there it prints out the file path that causes the issue:

1736414302021 -> sent 
{
  op: 'info',
  ns: 'storrito.connect3.core',
  symbol: 'storrito.connect3.success-panel/panel',
  id: '1126',
  session: '6140ecec-650a-4b22-b2c1-48ca17cabf8f'
}

1736414302023 <- received 2ms
{
  'arglists-meta': [ [], [] ],
  'arglists-str': '[state]',
  column: 1,
  'end-column': 12,
  'end-line': 4,
  file: 'file:/app/src/cljs/storrito/connect3/success_panel.cljs',
  'fn-var': 'true',
  id: '1126',
  line: 4,
  'max-fixed-arity': 1,
  meta: {
    arglists: [ 'quote', [Array] ],
    column: 7,
    'end-column': 12,
    'end-line': 4,
    file: 'storrito/connect3/success_panel.cljs',
    line: 4
  },
  'method-params': [ [ 'state' ] ],
  name: 'panel',
  ns: 'storrito.connect3.success-panel',
  resource: 'storrito/connect3/success_panel.cljs',
  'ret-tag': 'cljs.core/IVector',
  session: '6140ecec-650a-4b22-b2c1-48ca17cabf8f',
  status: [ 'done' ],
  'variadic?': 'false'
}

[PEZ]

Thanks! The Settings UI glitch is hopefully tracked on VS Code.

I notice that the response message has two entries with what looks like a relative path. Maybe Calva could check if the file exists, and if it doesn't, fall back on meta.file...

Did you try with the latest nrepl dependencies any?

About the workaround. May go without saying, but now you go to definition for a different truth. It's not the REPL truth. Sometimes it makes sense to go for the static truth, like if you have edited the files, but not recompiled (but why would you not recompile changes?). Sometimes it doesn't make as much sense as the REPL truth, like if you have redefined the function in some rich comment or a fiddle file, or the REPL prompt, and compiled that. I'm a REPL truth person 😄 generally.