jj-vcs
completion: avoid panic when completing non-normal paths
Fixes #6861
Checklist
If applicable:
- [x] I have updated
CHANGELOG.md - [ ] I have updated the documentation (
README.md,docs/,demos/) - [ ] I have updated the config schema (
cli/src/config-schema.json) - [x] I have added/updated tests to cover my changes
Maybe it's easier to normalize input to RepoPath and strip prefix from repo-relative path output (i.e. path instead of path.display() in template)? That will also fix Windows Bash issue. https://github.com/jj-vcs/jj/issues/7024
Easier in the sense that RepoPath uses / on either platform? Yes, unless we ever want to support completion on Powershell at some point. Idk, maybe slashes would be permissible there too, I've never understood when / works on Windows and when you need to use \... I also don't have a Windows machine to test that with.
If it's just Git Bash (and other POSIX shells in MinGW et al. environments), I'd lean towards sticking with the native path separator in general and fix the Git Bash issue separately by using slash_path on the result if COMPLETE=bash is used on cfg!(windows).
Easier in the sense that RepoPath uses
/on either platform?
Easier because the command output is also normalized (to repo-relative paths.) Post-processing would be simple if both inputs and outputs are in the canonical form. We can convert them back to backslash paths if needed.
@yuja, I went with your suggestion and switched to RepoPath. Took me a moment to realize, but this is actually much better on Windows as it allows mixing and matching forward slashes with backslashes. The completion will now always use forward slashes which indeed fixes #7024. I've verified this in Git Bash on Windows, but also using dynamic completion in PowerShell (on both Windows and Linux, actually). As PowerShell doesn't mind forward slashes even on Windows, I agree that this is preferable and there's probably no need to try to convert back to backslash-separated paths.