Suggestion: Improve ${workspaceFolder} variable

[k-jsmith01]

Hi, currently there is some kind of mismatch between VS Code and nvim-dap ${workspaceFolder} variable. VS Code docs define it as

the path of the folder opened in VS Code

, whereas nvim-dap states

The current working directory of Neovim

Former is a static directory reference provided as argument to VS Code startup. Latter is a directory, which can change dynamically. Some settings change cwd in Neovim, so this might result in surprising errors, when using a debug configuration and ${workspaceFolder}. In this case the only chance is to specify full absolute paths for things like pythonPath or cwd, which is suboptimal, as fragile configuration - also when .vscode is checked in to VCS.

What about following:
Check, if nvim has been started with an explicit directory as cli argument, e.g. by vim.v.argv. If so, use argument as "opened folder" for ${workspaceFolder}. Otherwise fall back to Neovim's current working directory for compatibility with status quo.

This better aligns with VS Code's definition and creates a more path-stable configuration.

Optional idea for launch.json:
It would be very nice to have a variable ${vscodeParent}, which automatically searches for the parent directory of .vscode (where launch.json resides in) and possibly traverse the file tree up, until found. Though first suggestion is a much more low-hanging fruit.

[mfussenegger]

Former is a static directory reference provided as argument to VS Code startup. Latter is a directory, which can change dynamically.

You can close and re-open the workspace folder from within vscode too.

Check, if nvim has been started with an explicit directory as cli argument, e.g. by vim.v.argv. If so, use argument as "opened folder" for ${workspaceFolder}.

Opening a folder is a completely different action than declaring a workspace/project folder. That's way more surprising for people who are used to vim instead of migrating from vscode.

---

I'm not going to make any changes in this direction.
What's on the roadmap is some kind of exensibility to make it easier to define custom ${} placeholders

[k-jsmith01]

You can close and re-open the workspace folder from within vscode too.

This would be an explicit action from the users point of view. In contrast, cwd changing in Neovim sometimes is more implicit. For example I am one of those unfacy guys that use Netrw explorer to navigate a directory tree. There is a setting that allows to auto-sync cwd with the navigated tree, which comes very handy. But in this case, it rather contributes confusion.

Opening a folder is a completely different action than declaring a workspace/project folder. That's way more surprising for people who are used to vim instead of migrating from vscode.

Yeah I tend to agree. I find myself rather cd in into the project and then just typing nvim out of habit - it wouldn't work this way.

What's on the roadmap is some kind of exensibility to make it easier to define custom ${} placeholders

This is great to hear. Personally I like to have project-specific settings, hence using launch.json within a project. If having custom placeholders, there is still the issue left, where to declare them. I think a common requirement is to exclude some of the settings from VCS, like absolute path reference for project root, speaking of alternatives to ${workspaceFolder}. What do you think of defining these in a separate environment file/ .env as commonly used?

I am wondering, if it also would make sense to have an auto-discovery setting for .vscode/launch.json file location, hence providing an easy way for users of project-specific settings to get project root and reference it within debug configuration.

[k-jsmith01]

FYI: After a bit more investigation, I probably go with just environmental variables in launch.json:

"pythonPath": "${env:PROJECT_ROOT}/.venv/bin/python",
"cwd": "..."

Setting PROJECT_ROOT and others becomes job of the IDE - not sure how this could be made easier from perspective of nvim-dap (apart from the auto-discovery suggestion).