-
Notifications
You must be signed in to change notification settings - Fork 236
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
Increase possibilities for yazi<->embedding editor integration #989
Comments
If Neovim doesn't provide an API for reading
I'm not quite sure what you mean by "loading" plugins. Normally, Yazi plugins don't need to be manually loaded; they are lazily loaded automatically after user actions (such as pressing a key). Are you referring to the initialization process of plugins? If so, that would involve loading an |
I love this idea. I think I will try it out soon.
I'm not sure if "plugin" is the correct term to use here. I'm looking for a way to
|
Tried this approach, but I quickly found out yazi could not be started when it's "hidden", possibly because it cannot draw to a screen. Opened #1004 which could be used to work around this limitation - the idea is to start |
In comparison to the LSP (language server protocol) which uses json RPC (https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/), several types of messages are supported:
Right now, the Is this a direction you could see yazi going? |
It sounds like the three modes you mentioned are already covered by the current DDS, but it's based on an asynchronous publish-subscribe model rather than a synchronous request-response model. For example, for the first mode, |
Message passing with the DDS itself should not be an issue. My issue is that there is no known real time communication channel that I could use from neovim. It's becoming clearer and clearer to me that at some point yazi.nvim might need its own plugin for various features. I will think about this idea more. Maybe there's something that could be done on the plugin level to make the communication possible. |
I think adding a new
Could you describe your needs? What are the things that DDS currently can't provide directly and must be done through plugins? |
Actually, I'm coming around to #1004 being a good approach. Let's reopen it and see if we can finish it. Previously I was confused about a few things, but I think this approach can work for me:
I will think about what the best way to include the plugin would be.. For example, when running yazi inside neovim, some keybindings should probably run plugin specific functionality, but when running outside of neovim they should use the default functionality instead. Have you thought about this kind of an approach? |
Please describe the problem you're trying to solve
In https://github.com/mikavilpas/yazi.nvim, I have ideas for some features that I think might require allowing a deeper level of interaction with editors that want to embed yazi:
Would you be willing to contribute this feature?
Describe the solution you'd like
Suggestions
Suggestion 1: programmatic access to yazi actions
The api could be disabled by default, and enabled with a command line flag such as
yazi --enable-rpc-api
, maybe even enabled in the user's configuration.Currently, yazi can send events via the data distribution service (dds), and the editor integrations can listen to these events. Events can also be sent to yazi via
ya pub
andya pub-static
.Even though the communication is now bidirectional, there are some difficulties with this approach:
m actions * n plugins
while there could bem actions + n plugins
if they were implemented once in yaziSuggestion 2: allow loading additional plugins from the command line
With deeper integration between yazi and neovim, some features only make sense when both yazi and neovim are running. I love the fact that yazi is a very composable tool and I can run it from the terminal as well as in my editor.
I want myself and other users to have a good experience in both environments. I think the best way to do this would be adding a new flag such as
yazi --load-plugin='~/.local/share/nvim/lazy/yazi.nvim/bundled-yazi-plugin/'
which would load this additional plugin that provides yazi.nvim specific functionality. When runningyazi
in the terminal environment, the plugin would not get loaded.Additional context
Benefits and ideas
Finally, I want to list some ideas and benefits that I think would come from these changes:
The text was updated successfully, but these errors were encountered: