Tab completion on path with space not working MacOS

[darrencl]

I would like to autocomplete path that has space in one of the sub-directory. The issue is, after it reaches the directory with space, the tab completion doesn't work anymore.

I just migrated from Ubuntu with older version of Python (Python 3.7) and iPython – I am pretty sure I did not encounter this issue before.

It would be very helpful to get this working, is there any workaround for this?

darren@Darrens-MacBook-Pro ~ % ipython --version
8.26.0
darren@Darrens-MacBook-Pro ~ % python --version
Python 3.12.4

Screen.Recording.2024-09-13.at.09.07.53.mov

[darrencl]

Hi @krassowski , is there any update on this?

FYI, I tried on Julia REPL and it also fails on autocompleting the directory after space. I also tried on both iTerm2 and default Terminal – both same results, so this behavior might be specific to MacOS' zsh, or is there any configurations to help with this?

[krassowski]

@darrencl you are welcome to submit a PR or help someone with submitting one, I can volunteer to review it.

[darrencl]

@krassowski thank you for replying! Happy to try and tackle this issue when I have time if maintainer/member could guide which parts to look at/make changes for this.

From my update that this also happens on Julia REPL – do you think this is more of zsh's plugin/API rather than iPython? In zsh terminal itself, though, there is no issues with the autocompletion.

[krassowski]

My hunch would be that this is an issue in tokenization/regex used for path completion (or in deciding whether to invoke path completion) in IPython - there is dedicated logic for it here, it does not use any logic of the underlying shell.

[darrencl]

Hi @Yann-P @Carreau , thanks for looking into this, but I just updated my ipython from the main branch (v9.0.0.dev) and the issue still persists. I am also on an updated MacOS.

Please refer to screen record below.

Screen.Recording.2025-02-13.at.13.23.44.mov

[Carreau]

Sorry, the mentions of this PRs were not meant to close it. GitHub was overeager when parsing the commit message saying [...] I want to fix #14516 [...] and assumed it was actually fixing it.

[Yann-P]

I'm still intending to fix this, the 2 MRs are some refactoring to make the completer code easier to work on