-
Notifications
You must be signed in to change notification settings - Fork 469
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
Allow ya sub
to wait for a yazi to start
#1314
Comments
Fixes a bug where grepping or replacing with `<c-s>` or `<c-g>` would pick Neovim's current working directory instead of the directory of the file. This needs another look after sxyazi/yazi#1314 is resolved. Maybe it can be improved.
#293) Fixes a bug where grepping or replacing with `<c-s>` or `<c-g>` would pick Neovim's current working directory instead of the directory of the file. This needs another look after sxyazi/yazi#1314 is resolved. Maybe it can be improved.
Background ========== When yazi is started too late, it can happen that we don't know what the last_directory was when yazi has exited. This currently happens when `ya` is started too late - yazi has already reported its `cd` event before `ya` starts and yazi.nvim cannot capture it. The issue can be tracked in sxyazi/yazi#1314 Issue ===== Currently yazi.nvim works around this limitation by using the parent directory of the input_path as the last_directory since it's a good guess. However, it looks like this has never worked reliably due to a bug in the implementation. The correct directory was calculated, but it was not assigned to the last_directory field in the state - it was ignored and had no effect. Solution ======== Assign the correct directory to the last_directory field in the state.
Background ========== When yazi is started too late, it can happen that we don't know what the last_directory was when yazi has exited. When this happens, yazi has already reported its `cd` event before `ya` starts and yazi.nvim cannot capture it. The issue can be tracked in sxyazi/yazi#1314 Issue ===== Currently yazi.nvim works around this limitation by using the parent directory of the input_path as the last_directory since it's a good guess. However, it looks like this has never worked reliably due to a bug in the implementation. The correct directory was calculated, but it was not assigned to the last_directory field in the state - it was ignored and had no effect. Solution ======== Assign the correct directory to the last_directory field in the state.
Background ========== When yazi is started too late, it can happen that we don't know what the last_directory was when yazi has exited. When this happens, yazi has already reported its `cd` event before `ya` starts and yazi.nvim cannot capture it. The issue can be tracked in sxyazi/yazi#1314 Issue ===== Currently yazi.nvim works around this limitation by using the parent directory of the input_path as the last_directory since it's a good guess. However, it looks like this has never worked reliably due to a bug in the implementation. The correct directory was calculated, but it was not assigned to the last_directory field in the state - it was ignored and had no effect. Solution ======== Assign the correct directory to the last_directory field in the state.
Background ========== When yazi is started too late, it can happen that we don't know what the last_directory was when yazi has exited. When this happens, yazi has already reported its `cd` event before `ya` starts and yazi.nvim cannot capture it. The issue can be tracked in sxyazi/yazi#1314 Issue ===== Currently yazi.nvim works around this limitation by using the parent directory of the input_path as the last_directory since it's a good guess. However, it looks like this has never worked reliably due to a bug in the implementation. The correct directory was calculated, but it was not assigned to the last_directory field in the state - it was ignored and had no effect. Solution ======== Assign the correct directory to the last_directory field in the state.
I've been thinking about this issue, and I kind of feel like something like If I understand correctly, you expect the But the problem is that during those few hundred milliseconds while waiting and retrying, messages can still be lost. So this method doesn't seem reliable, and we can't set the delay too low because that would consume a lot of CPU without addressing the problem fundamentally. Can you describe the functionality you're aiming for in more detail? For example, where do you expect the hover state to come from — inside Neovim or outside? And if an external Yazi instance sends a new hover message, what's your expected behavior? |
Actually, what I think I am looking for is a way to receive the file that yazi is hovering. Maybe I thought it might be possible to receive messages with ya even before any yazi has started broadcasting them. Here is what I see when yazi is opened. The initial hover event is lost when the embedded yazi is started (the background color of the file changes when this happens). Only after another file is hovered, the color changes. hover.mov |
Please describe the problem you're trying to solve
As you know, yazi.nvim uses
ya sub
to listen for hover events from the yazi instance that is started inside of neovim. I just found out that all this time I have been testing that feature, I have had some extra yazi instances running in the background. I killed them and learned the first hover event from the yazi that starts up is very difficult to read.I think the reason for this is that
ya sub
requires the yazi instance to have started (the DDS has to be active before starting). Yazi.nvim has to start yazi first because of this, but a side effect is that the hover event has already been sent and is lost because of this timing related issue.I can get the first hover event to work when a yazi is already running outside of neovim when yazi.nvim creates a second one, for example.
Would you be willing to contribute this feature?
Describe the solution you'd like
How about adding a new flag such as
ya sub --wait-for-yazi ...
that could be given to block and wait?I could then reverse the order and start
ya
first, andyazi
immediately after.Additional context
It might be a good idea to keep the current behaviour of failing if a yazi is not active to avoid breaking compatibility with any integration that might depend on this.
The text was updated successfully, but these errors were encountered: