zsh-autocomplete: Completion not triggering after `e14687b80`
zsh-autocomplete
version: e14687b80428eb1c22069023b5f12a2ef4f55bcb (works) → 85fdb5750d6bddc621df6ba447027c97fadf2bd4 (does not work) → 112b791326007623c7fdb6234d2f9feb74dae538 (does not work)- Zsh version: zsh-5.7.1-0-g8b89d0d
- Framework: none
- Plugin manager: none
On one of my machines autocompletion does not work at all—there is no output or interaction when pressing <kbd>tab</kbd>. I’ve narrowed down the last working commit to e14687b80.
$ cd ~zsh-autocomplete
$ git switch main # Make sure you test with the `main` branch.
$ git pull # Update to the latest commit.
$ cd $(mktemp -d) # Create a temp dir and enter it.
$ # Restart Zsh without config files or environment variables in this dir:
$ exec env -i HOME=$PWD PS1='%# ' TERM=$TERM zsh -f
% touch file{0..3}.txt # Create some files to test autocompletion
% cat file <TAB> <TAB> # Demonstrate stock autocompletion
file0.txt file1.txt file2.txt file3.txt
% # Checkout latest version as of today
% git -C /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete checkout 112b791326007623c7fdb6234d2f9feb74dae538
% source /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete/zsh-autocomplete.plugin.zsh
% cat fi <TAB> # No output or interaction
% exec env -i HOME=$PWD PS1='%# ' TERM=$TERM zsh -f
% # Checkout last working version
% git -C /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete checkout e14687b
% source /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete/zsh-autocomplete.plugin.zsh
% cat fi # Autocomplete works
file
file0.txt file1.txt file2.txt file3.txt
all matches
file0.txt file1.txt file2.txt file3.txt
common substring: file.txt (press Shift-Tab to insert)
% exec env -i HOME=$PWD PS1='%# ' TERM=$TERM zsh -f
# Checkout first commit after e14687b
# 7041784 is technically the first commit after e14687b, but 85fdb57 fixes some clobber errors
% git -C /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete checkout 85fdb5750d6bd
% source /home/pawlu/.oh-my-zsh/custom/plugins/zsh-autocomplete/zsh-autocomplete.plugin.zsh
% cat fi <TAB> # No output or interaction
As always, thanks for sharing your project!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 45 (25 by maintainers)
Commits related to this issue
- Make sure we pass absolute paths to `autoload` Relative paths don't work. Fixes a problem mentioned in issue #282. — committed to marlonrichert/zsh-autocomplete by marlonrichert 3 years ago
- Ensure completion widgets always complete Fixes part of issue #282. — committed to marlonrichert/zsh-autocomplete by marlonrichert 3 years ago
- Add logging — committed to marlonrichert/zsh-autocomplete by marlonrichert 3 years ago
- Change logging strategy Hopefully fixes issue #282. — committed to marlonrichert/zsh-autocomplete by marlonrichert 3 years ago
Runs perfectly 😄
@paw-lu Please try updating to the latest commit and see if that helps.
@paw-lu Do you think you could put together a minimal, reproducible test case for this that does not use
zsh-autocomplete
? Then I can ask about it on the Zsh mailing list.It seems that for some reason, redirecting to that fd when inside a pty breaks things for you. No idea why. But perhaps I can add a test inside the pty to check if the fd is writable.
OK, well, that’s not handy. I wonder why that doesn’t work on CentOS?
@paw-lu Can you give me your
$OSTYPE
? Perhaps I can conditionally remove it.I thought you said, though, that 85fdb57 was the first commit that broke it for you? Those redirects were already present in e14687b and that worked for you. It makes me think that it’s not the redirects themselves that are the problem, but rather the way I create the file descriptor.
@paw-lu Can you try reverting commit 85fdb5750d6bddc621df6ba447027c97fadf2bd4 line by line and see which one fixes the problem?
@jocastaneda @paw-lu Thank you for the kind words! 🤗
If you use my software on a regular basis, please consider being a sponsor. 🙂
yep!
OK, that should be fixed now. That doesn’t explain the other bug, though. 🤔
Well, that looks like it works. I’m kind of baffled by this one.
What happens if you paste this into the command line?
Can you update to fd801e4ce6e31c2b4e4985a769d8db80da50b098 and try this?
@paw-lu Can you update to 20a301d and then try this?
And then check the logs again.
OK, try this:
Then check the logs again.
@paw-lu Can you go to
${XDG_DATA_HOME:-$HOME/.local/share}/zsh-autocomplete/log
and have a look what is in the newest log files there? Any error messages?Actually, sorry, no, that doesn’t help. As you said yourself, that’s fixed in 85fdb57.
I wonder if it has something to do with you using zsh-5.7.1-0-g8b89d0d. 🤔
Thanks! That makes it a lot more clear what I need to fix.
@paw-lu Are you saying that the first bad commit for you is 70417848c6cd0715955ce4cbaf4b9ed779c7402c?
Yes, that’s what I meant.
Aha:
I must have something in my environment that’s making it work when I don’t use a fresh clone. I’ll have to investigate.
It works fine for me on the latest commit:
Have you tried reinstalling?