-
Notifications
You must be signed in to change notification settings - Fork 383
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
Labels
feature
New feature request
Comments
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Jul 30, 2024
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.
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Jul 30, 2024
#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.
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Oct 16, 2024
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.
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Oct 16, 2024
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.
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Oct 16, 2024
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.
mikavilpas
added a commit
to mikavilpas/yazi.nvim
that referenced
this issue
Oct 16, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: