New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some commands sometimes show empty panes in fish shell #633
Comments
This is a very strange issue indeed due to this not being consistent, the same command and code is run by fzf-lua so the inconsistency is making it hard to identify what’s the source of the issue. The common denominator between the commands that fail seems to be a lua table input into
In the meantime if you can fins a way to consistently reproduce this with steps then I’d be able to solve it easily from my end. |
I unfortunately haven't been able to find a consistent way of reproducing it. Although something weird that I saw last night when running the If you want me to add some kind of logging or print statements somewhere you're suspicious of, just let me know. I'm guessing this may be a weird interaction of my system (and likely a mistake on my part), so it's probably going to be incredibly hard to reproduce outside of it. I'm new to fish, so I probably messed something up. One thing I'll mention given the weird interaction I had with that sort of race condition: I managed to make my fish config significantly faster than my ZSH one (startup time being ~10ms). My guess is that this probably doesn't really matter, but I guess more info doesn't hurt |
Tysm for the details! anything helps. I'm pretty sure this is not "your fault", any shell and any setup should work regardless of circumstanes, as long as you're patient and willing to work with me on this I can assure you we will not leave a rock unturned and get to the bottom of this issue. I was able to identify what I believe is the common ground between the failing commands, they are all using the stdin input redirection directive Here's where I get confused: in order to avoid shell woes the fzf command is explicitly wrapped with POSIX shell using Lines 178 to 184 in cddb1c3
The commands that never fails ( According to the
jobstart({cmd} [, {opts}]) *jobstart()*
Spawns {cmd} as a job.
If {cmd} is a List it runs directly (no 'shell').
If {cmd} is a String it runs in the 'shell', like this:
:call jobstart(split(&shell) + split(&shellcmdflag) + ['{cmd}'])
(See |shell-unquoting| for details.) Althought this might happen because of Lines 71 to 75 in cddb1c3
This leaves me to suspect a delay (as you mentioned, sometimes it does open properly after a while) while executing the Although I'm still unsure why this would cause such a behavior, can you post the output of the below:
:lua print(vim.env.FZF_DEFAULT_COMMAND)
:lua print(vim.env.FZF_DEFAULT_OPTS) |
I really appreciate the help. I love this library and have used for more than a year now, I'll do anything I can to help! I also appreciate explaining what's going on.
Smart. I agree this makes it more confusing that this weird behavior would be terminal dependent, but I'm still not knowledgeable enough of fish to be aware of possible differences. I'll mention that, because of how fish works, not only I managed to get a significant speedup on non-interactive startup of fish, I was also able to add more stuff that I couldn't with zsh —because otherwise I would be able to notice a performance impact—, which means I'm loading functions and aliases that I use a lot in interactive sessions that didn't use to be there before (I don't think this is the issue, but probably something to keep in mind). I can't easily "not load them in non-interactive" because they're autoloaded functions (instead of aliases).
My default command is using fd, a print(string.format("FZF_DEFAULT_COMMAND: %s", vim.env.FZF_DEFAULT_COMMAND))
print(string.format("FZF_DEFAULT_OPTS: %s", vim.env.FZF_DEFAULT_OPTS))
One (even weirder) thing, I'm currently on PTO so I'm using my work computer less and this problem is much harder to manifest in my personal computers. One of them is identical to my work computer, a macbook pro from last year, and an old intel mac mini. My dotfiles are in github and the same across the board, so the biggest difference would be me running much heavier applications on my work computer (I usually just SSH into my personal ones from my iPad, and not running things like Docker or the MDM software). I'll also mention that I use neovim within tmux almost exclusively, although I was able to reproduce outside of tmux (in case you wanted to rule it out). |
I just took my work computer to see if I could reproduce again, and the problem was there immediately. I even saw a flash of I unset all my |
I recorded a video, if you pay attention to the beginning of the Screen.Recording.2023-02-10.at.00.25.26.mov |
While I had the system in this state, I tried changing my $SHELL to zsh. It doesn't fail... but while recording I'm just realizing I'm seeing the Screen.Recording.2023-02-10.at.00.31.11.mov |
Ty @iovis, this is very helpful.
I can clearly see it in both your videos, still no idea where it’s coming from but it’s good to know it’s happening in all commands so I can invalidate some of my other assumptions.
Running any command with I’m suspecting something in your shell configuration as this issue would have probably come up before by many others but I can’t pin point what… armed with this new information I’ll keep digging in the code and try to come up with a better idea. |
One clarification I forgot to ask, is the work computer using the same dotfiles? If so, are your dotfiles (or at least the shell profile) online? If I can reproduce this on my system with your dotfiles I would be able to solve it much faster. |
Yes, same dotfiles. You can find them here:
I managed to reproduce with a very minimal configuration (video attached): # ~/.config/fish/config.fish
/opt/homebrew/bin/brew shellenv | source # This is the path for `nvim`, `fzf` and friends sh -c "$(curl -s https://raw.githubusercontent.com/ibhagwan/fzf-lua/main/scripts/mini.sh)" In the video, I ran the commands with minimal.mp4 |
Ty @iovis! I just tried the same exact setup on a OSX, neovim 0.8.3 with fzf 0.37 with your I’d like to try something else, I have a hunch that may or may not be true that this might be related to the new load event added with fzf 0.36, would you be able to download fzf 0.35.1 Darwin binary from fzf releases, set |
Can't say I'm surprised, I seem to only be able to reproduce it consistently under very heavy load.
For a second I got excited, because I managed to make fzf.35.mp4 |
For context, under the same load, it works fine in ZSH: zsh.mp4Sorry that it's a bit hard to read with the bg being set to magenta for some reason |
Also, when reproducing for # ~/.config/fish/config.fish
set -gx XDG_CONFIG_HOME $HOME/.config
set -gx XDG_DATA_HOME $XDG_CONFIG_HOME/.local/share
set -gx XDG_CACHE_HOME $XDG_CONFIG_HOME/.cache
fish_add_path /opt/homebrew/bin |
What is considered "heavy load"?
No worries, I should probably adjust the defaults in to look somewhat normal on the default colorscheme.
I used the same as this was inside the |
This is what’s so confusing here, there should be no point in the code where fish shell is run or matters, at all, anywhere a shell command is used is wrapped with During the plug-in development I did notice some commands behave differently if |
I just tried stopping everything thinking it would come back to normal and it's still reproducible, so I'm now even more confused of why it's easier to reproduce on my work computer. The biggest difference with my personal computers would be the MDM software, but I still have managed to reproduce in my personal computers at some point or another (just less frequently).
Do you want to give me some code to run manually in my editor to see if I can pinpoint which line is the one failing? I can compare between ZSH and fish to maybe see if there's any difference |
I think this is the best route, next chance I’m on the computer I’ll create a debug branch and pepper the code with some “before” and “after” prints, you can then set Lazy to said branch and we can examine the output from |
Sounds good, I appreciate the patience helping me debug this! |
Can you try branch 633_debug? It has prints before and after suspected areas of the code, paste the output of |
fish
zsh
|
Ty @iovis, this just got even stranger lol
This is the code part: Lines 260 to 264 in 2d675a6
Essentially all the fzf-lua code was executed and now neovim is waiting for the terminal job (fzf) to exit. Another oddity is an exit code not mentioned in fzf manual:
|
I can reproduce the error |
Exit code 129 is apparently
I’ll admit, this is quite the bug we got here lol, but at least I know now I need to focus on alternatives to redirecting the fifo into |
Want me to run the |
I wonder if the underlying |
Just switched the input redirection to |
@ibhagwan I think you nailed it! I've been trying to break it with my full config and I can't, it looks rock solid. I don't even see the Let me try again with clean configs and zsh and maybe heavy load again. But this looks promising! |
Close but not there yet! It seems it cuts the input arbitrarily at 10 items, for example, try I’m still trying to find a solution for this, but otherwise it’s a solid solution, it’s also better to let fzf handle the command process using |
It's the |
@ibhagwan I just changed: FZF_DEFAULT_COMMAND = string.format("tail %s", vim.fn.shellescape(fifotmpname))
-- to
FZF_DEFAULT_COMMAND = string.format("cat %s", vim.fn.shellescape(fifotmpname)) And it works without limiting the output, not sure if that helps |
Ofc it helps, this is great, I’m just sure how cat handles ongoing input from a fifo file, I gonna do some more research and you might have just found our solution :) |
I'm investigating in the meantime, and it seems like |
The question is, why does this even matter, In any event the |
The second link you posted seems to be a clue as to what may be happening here, but again, we’re using |
It's working amazing.
Do you think you can give me an My hunch right now is that |
Actually, even if termopen is using |
I've been trying with:
But I couldn't see any error |
In any case, thank you so much for fixing this issue and for your patience ❤️ |
a294a83 - I'm on a flight and the plane WiFi is blocking my git ssh connection, I had to do this from the web interface (first time), hopefully I didn't mess up anything :-) Tysm @iovis for your patience! after much joint efforts I think we've come to the conclusion of this quite mysterious bug.
That is the only way to explain it but that would be quite the conundrum, perhaps this is isolated to
Using
Idk if this rabbit hole is worth pursuing any more than what we already did :-)
Ty again @iovis, it's been a pleasure working with you! |
Now fixed with 1df9249, no more magenta on default colorsceme lol, beats me why linking to a cleared highlight group would choose |
Much easier to read haha. Btw, the fix has been working wonderfully on my end these days, tysm for looking into this! |
Info
nvim --version
: v0.8.3fzf --version
: 0.37.0 (brew)mini.sh
Description
I've been trying to diagnose this one by myself, but I can't figure it out anymore. Maybe you can help me debug this better.
So, I recently switched to Fish as my shell (from ZSH). Everything was working fine, till I started to sometimes see
:FzfLua buffers
behave strangely:No error, just that lonely
^[i
right there (it's always there when this happens). The thing is, it's not consistent (although once it starts, it'll stay there). I could reproduce with the minimal setup.It also seems like it may somehow be related to commands related to vim. These are some commands that stop working when this happens:
But other commands do work normally, even when this starts happening, like:
If I run neovim from ZSH, this doesn't happen, it works as expected.
My guess is that something is breaking somewhere, but not showing the error for some reason. I checked
messages
and stuff, but couldn't find anything.Do you know what could be going on or how I could debug this further?
The text was updated successfully, but these errors were encountered: