Closed benlubas closed 10 months ago
This is a copy from issue #8 from the previous fork.
Last comments were about us considering going with an event system based in lua vs using Vim autocommands. I do still think this is the right path to go though in either case we don't know enough about "how" and "when" hydra does stuff so an event system might be a reach right now. One of us (probably me) will need to dig into the internals of hydra to get an idea of how hard it would be to do this one way vs another.
Here's the argument for autocommands:
There's first class support for them in the lua API with: nvim_create_autocmd()
, nvim_create_augroup()
, and nvim_exec_autocmds()
and others. The last of which has additional functionality on top of vanilla vim script that allows attaching arbitrary data to the fired event.
Main advantages:
require("hydra")
for as long as possibleAll of those are fantastic points
A couple things here
Multiple actions on the same event This is also handled by events. We just call every listener for an event each time the event is called. Additionally, we have the same ability to attach arbitrary data via a callback. Lastly, by using our own event system, it gives us the ability to use coroutines/other async methods should we decide to allow that. I don't believe (I could be wrong though) that vim autocommands are asynchronous
augroups for free You are completely correct here
Attach them from everywhere without requiring loading the plugin This is, at best unimportant (imo). It is pretty easy to break out the event system away from the rest of hydra so you aren't loading the entire hydra stack to manage event handling. That doesn't make you wrong, just that its easy enough to solve while still keeping lazy loading hydra possible
Consistency I want to argue with you here but you are correct.
It's way less code Facts lol
My biggest reason for wanting to go with a lua event system as opposed to using autocommands is that it is much easier to debug code when it is not diving in and out of the vim stack. I acknowledge that debugging ease alone should not make a decision though.
Do you know when the various nvim_autocmd
functions were added to the API? My other concern is introducing reliance on nightly apis. I understand that alot of users use the nightlys because they want the new APIs as they come, but I am not personally open to the idea of forcing an existing userbase to update to a nightly version of neovim just for a new feature we want.
I believe the nvim_autocmd
functions are on stable so this last argument is likely moot, but it should be considered for any new features we wish to add. Hydra has a pretty big userbase and we want to stay as compliant as possible with them (especially as it seems that the original is effectively dead).
All of that said, this is a feature I am interested in but not enough to make it. So at the end of the day, if you wish to do it with Autocommands, you absolutely can :)
If we do go that route (or if we go the callback route), we need to document what the data package is that we are attaching/returning.
Digging into the code a bit, there is already a quasi event system in place
Hydra supports adding custom on_enter and on_exit
callbacks to hydra. So in theory this should be a minimal change regardless of which route we go, though it does raise the question of if this is needed or not.
Additional details, there is a util.add_hook_before
function, however there is no add_hook_after
function. We could probably add that, though I do wonder how much that would impact the overall philosophy behind hydra (remember that you can chain heads and therefore you may not want to call something after each head is completed)
when the various nvim_autocmd functions were added to the API?
Started showing up in like 0.5 or something. I use them right now running 9.4.
I agree using nightly features should be configurable, off by default, and clearly labeled.
I don't know how I missed that 🤦
This is good enough for me. It would be more convenient to have global enter and exit just so I can set it up only once, but that's not the end of the world.
It would be more convenient to have global enter and exit just so I can set it up only once
I don't know that hydra has a sort of "global" configuration, but there is nothing saying you cant make that a thing and just add that into the on_enter
and on_exit
functions for each hydra ;)
I'm going to close this for now, might revisit it in the future.
porting https://github.com/nvim-island/hydra.nvim/issues/8
Firing
User
autocommands after a hydra gets activated/deactivated would be cool. My use case is using it to immediately refresh my status line which I use to show an active hydra:Currently I have to wait for something else to refresh it (which isn't a big deal, it's just not ideal).
As far as implementation details, there should probably be 4 of these:
HydraEnterPre
- fire when we're about to enter but the hydra state hasn't changed at allHydraEnterPost
- fire after the hydra is activeHydraLeavePre
- fire before the hydra is deactivatedHydraLeavePost
- fire after the hydra is deactivatedEach one could also include some data in the data field (see
:h nvim_exec_autocmds()
), though I'm not sure what type of data would be useful (I wouldn't need any for my use case)