[Feature Request] HydraEnter/Exit autocommands

[benlubas]

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 all
• HydraEnterPost - fire after the hydra is active
• HydraLeavePre - fire before the hydra is deactivated
• HydraLeavePost - fire after the hydra is deactivated

Each 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)

[miversen33]

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.

[benlubas]

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:

• Multiple actions on the same event. If a user and some other plugin both want to take action on some autocmd, we get this for free with autocommands. In our own system we would have to manage attaching and detaching event handlers, track them with IDs, etc.
• augroups for free, associate all the autocmds from one plugin/user under a single namespace, easily detach all of them at once.
• Attach them from everywhere without requiring loading the plugin. might be useful in a few lazy loading cases, where you want to avoid calling require("hydra") for as long as possible
• Consistency with the rest of the editor means more people will be familiar with it, behavior is well known and documented within nvim itself
• it's way less code

[miversen33]

All 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.

[miversen33]

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)

[benlubas]

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.

on_enter and on_exit

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.

[miversen33]

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 ;)

[benlubas]

I'm going to close this for now, might revisit it in the future.