Closed eyJhb closed 1 month ago
I am not able to reproduce the behavior.
The dlv
configuration uses the value of the customizable var dape-cwd-fn
to resolve command-cwd
.
The default value for dape-cwd-fn
is 'dape--default-cwd
.
(defun dape--default-cwd ()
"Try to guess current project absolute file path with `project'."
(or (when-let ((project (project-current)))
(expand-file-name (project-root project)))
default-directory))
If I had to guess it's either
project.el
expand-file-name
follow symlinks.You are always able to override the value of any keyword, like:
I found the issue. It was projectile being annoying as usual, and therefore overriding how project-root
acts, or something. At least that was the cause of me being given the absolute path, instead of the symlink.
Anyways, that was the last straw, and I have now removed projectile, and it will not haunt me anymore!
Thanks for this project, highly appreciate it. Excited to start playing with it :)
It seems like dape is resolving symbolic links, and using the absolute path of a file/directory, which shouldn't be used. This causes issues with e.g. delve, which then gets
command-cwd
as the absolute path, butcwd
is the symbolic link path.This mismatch means, that breakpoints, etc. does not work. Is there any way to work around this?
Look at the image attached below, where it can be seen. It shows the path
command-cwd "/state/stash/stash/python-dap-test
, but it should instead be"/home/eyjhb/stash/python-dap-test
(please ignore it says Python, it's a Golang project, I was just testing Python AND Golang in the same dir).Ideally, it shouldn't resolve the symbolic link, and also, I'm not sure if dape is the actualy culprit here. It just seems like it might be.
EDIT: this is my config, there isn't anything special, but posting for completeness.