Skip to content
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

Open
1 task done
mikavilpas opened this issue Jul 19, 2024 · 2 comments
Open
1 task done

Allow ya sub to wait for a yazi to start #1314

mikavilpas opened this issue Jul 19, 2024 · 2 comments
Labels
feature New feature request

Comments

@mikavilpas
Copy link
Contributor

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?

  • Yes, I'll give it a shot

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, and yazi 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.

@mikavilpas mikavilpas added the feature New feature request label Jul 19, 2024
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.
@sxyazi
Copy link
Owner

sxyazi commented Jan 25, 2025

I've been thinking about this issue, and I kind of feel like something like ya sub --wait won't really solve your problem.

If I understand correctly, you expect the --wait behavior to create a loop that checks every few hundred milliseconds to see if the Yazi server has started, and if it has, it connects to it.

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?

@sxyazi sxyazi added the waiting on op Waiting for more information from the original poster label Jan 25, 2025
@mikavilpas
Copy link
Contributor Author

If I understand correctly, you expect the --wait behavior to create a loop that checks every few hundred milliseconds to see if the Yazi server has started, and if it has, it connects to it.

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

@github-actions github-actions bot removed the waiting on op Waiting for more information from the original poster label Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature request
Projects
None yet
Development

No branches or pull requests

2 participants