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 · 0 comments
Open
1 task done

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

mikavilpas opened this issue Jul 19, 2024 · 0 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.
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

1 participant