I’m thinking of running a course by doing rustlings together. Alas I find it to be horribly slow!
I’ve solved the 1st issue: don’t ctrl-click on a hyperlinked file in VS code’s terminal, as it deceptively invites you to do. That takes 3 seconds ! Instead locate that same file in VS code’s explorer, which opens it instantaneously. (I had exo-open set to Emacs for text/rust and changed it to Visual Studio Code – maybe there’s a more light-weight opener? Even though the tooltip adds "file:/", Visual Studio Code URL Opener does not work.)
The other point I’m stuck on: from the message it sounds like rust-analyzer and rustlings have a contention on target/debug/.cargo-lock. Unlike cargo --target-dir, neither rust-analyzer nor rustlings seem to have any option to avoid colliding.
I dug into this a little bit, and this is really a peculiar situation and it's fascinating.
rustlings will emit a "hyperlink" ANSI escape sequence (i.e. OSC 8, or \x1b]8) when showing the file path. when you run rustlings inside a terminal, clicking the link will open your system's default file editor (or whatever is registered to open the file:// url).
the vscode terminal emulator is powered by xterm.js (the ticket is #39278, which was marked as complete in e0335f), since ANSI escapes are parsed and handled at low level by xterm.js directly, clicking such links still trys to open the system's editor.
ironically, if it were just plain text, without the hyperlink escape sequence, the terminal emulator will not treat it as a url. when the text is rendered by the vscode terminal window, vscode will try to detect url-like elements, and recognize it was a valid file path, then turn it into a clickable link.
but this time, this link is handled by vscode, if you hover your mouse, you'll see the tooltip "open file in editor (ctrl + click)". in comparison, the "proper" hyperlink with terminal escape sequence will show a tooltip of the full url (e..g file:///home/username/path/to/file.txt (ctrl + click)) when you hover.
actually, rust-analyzer does have a setting for that, it's rust-analyzer.cargo.targetDir:
Thanks for figuring out why VS code doesn’t just do the right thing for terminal hyperlinks (at least optionally, if within workspace etc.) Not that it helps, but good to know!
As for the option, I had been going over rust-analyzer --help to find it and ask VS code to pass it. Instead it’s there as an option to set directly in VS code – even labelled right. Just the explanation of true is rather wishy-washy. Instead of “a subdirectory of the existing target directory”, leaving us guessing, it should name <WORKDIR>/target/rust-analyzer or <TARGETDIR>/rust-analyzer!
This is a life-saver. Thank you so much. I just wonder why setting it to true is not the default! I always took care to pass the option to cargo so I could get on with life, without VS code blocking me. At least the trade-off with disk-space should be prominently explained, so everybody can choose easily!
! Instead locate that same file in VS code’s explorer, which opens it instantaneously. (I had exo-open set to Emacs for text/rust and changed it to Visual Studio Code – maybe there’s a more light-weight opener? Even though the tooltip adds "file:/", Visual Studio Code URL Opener does not work.)