As mentioned on #1009, "Tab completion [of paths] only works when using forward slashes, and even then only on paths which do not include spaces (quoted or unquoted)." (@jdmarch) This affects all platforms, but is mostly an issue on Windows.
I had a brief look at the code for this, but it's fairly convoluted, and I don't want to start breaking tab completion just before a release.
Sounds good. Ideally, we should add a few failing tests first by creating paths with spaces in a temp directory and calling completion on those. Then we can actually fix this for good, so it doesn't come back to bite us again later.
For now, good thing to have it filed here, thanks. I'll mark it tentatively for 0.13.
Another problem with tab-completion and paths on windows is that paths are case insensitive on windows and when a path is matched the case of the file on disk can replace the string at the prompt causing problems if there are variables around that should match the original string.
variable in memory: transition
file on disk: Transition_x, Transition_y
now making the variable inaccessible
@jstenar, thanks for pointing that out. That means that we should make absolutely sure that we filter out our matches list to respect the casing of what's been typed so far. Furthermore, if the case difference is not on what's been typed already but on the completions themselves (think variable 'transition' and files 'tranSitionX' and 'tranSitionY'), then we should normalize the file completions list against the variable completions.
This will be somewhat ugly code, because it introduces a coupling between two stages of the completion process that in principle should be independent, but they become dependent because the windows filesystem is retarded.
A closely related issue is that the magic works without % with forward slashes, but chokes with backslashes:
In : cd d:/
In : cd d:\
File "<ipython-input-20-2e0cf40b1d2f>", line 1
SyntaxError: invalid syntax
In : %cd d:\
This feels inconsistent to me.