Remove TODOs about using path-slash
to handle escapes
#1841
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I considered opening an issue or discussion question about this, but I figured it would be more efficient to use a PR, which can be merged or not according to whether I'm correct to think the change these TODOs recommend should not be attempted.
Why I think those TODOs shouldn't be planned
The
to_unix_separators
andto_windows_separators
functions ingix_path::convert
had TODO comments saying they should use thepath-slash
crate "to handle escapes". These comments were added as part of e4f4c4b (#397) but the context there and in the broader related issue #301 does not seem to clarify the basis for this.It is not really clear what handling escapes would entail here, and it seems like there is not a way to do it without substantially changing the interface of these conversion functions in
gix-path
, which currently take a single argument representing a path and return a single string-like value also representing a path. If escape sequences appear in the input to such a path conversion function, it would not have a way to know if they are meant literally or as escape sequences. (An analogous concern applies if a function is to add escape sequences in its return value; it would have no way to know if the caller expects them.)Furthermore, while
path-slash
can convert some\
paths to use/
instead, it does not appear to do anything related to handling escape sequences or distinguishing which occurrences of\
or any other character may be intended as part of an escape sequence. Its documentation does prominently mention that\
in escape sequences should not be converted to/
:But it looks like the part about
\
characters used for escaping is meant as advice on how and when to usepath-slash
, rather than meaning thatpath-slash
would itself be able to distinguish between\
characters meant as directory separators and\
characters that perform quoting/escaping.An alternative to removing the TODOs
One possible alternative to removing these TODOs would be to change them to express a plan to switch to
path-slash
, but for a different reason. If distinguishing\
is something these conversion functions should not do, and thatpath-slash
does not do, then that would still support usingpath-slash
, just for the reason of convenience rather than extra functionality.However, I think we should probably also not switch to
path-slash
for this particular use at this time, for the reasons detailed in the part of #1840 (reply in thread) that describes some limitations ofpath-slash
.