Obviously I've contributed quite a few hooks to agentic already, but I just keep finding that I'm still missing hooks for doing something as basic as handling model changes.
For example I've realized I need a hook for session/set_config_option and session/set_model so I can update my header and status lines when the model is changed mid-session because apparently ACP doesn't send a config_option_update when the model changes directly via session/set_model.
I'm sure I'll keep finding a need for hooks into the other calls too. I feel like I'm playing whackamole with adding new hooks and don't feel like it should require a new PR every time a new ACP method is added. That's probably annoying for everyone.
So I was thinking about it and maybe the best path for hooks would be to pass them into the ACPClient and invoke hooks in ACPClient:_send_request and just identify hooks by their method name?
There could be a generic hooks that runs before the request, and another that runs after. As new ACP methods are added, no new code would be needed, as it's all handled directly at the client level when the requests are being made.
This could also be done for notifications at ACPClient._handle_notification which could invoke hooks based on the method. For non-notification messages, the post hook on the original request would be called.
Perhaps something like this:
Perhaps something sort of like this main...chancez:agentic.nvim:pr/chancez/acp_hooks. I haven't tested it, just putting it up as an example of what I'm thinking.
Obviously I've contributed quite a few hooks to agentic already, but I just keep finding that I'm still missing hooks for doing something as basic as handling model changes.
For example I've realized I need a hook for
session/set_config_optionandsession/set_modelso I can update my header and status lines when the model is changed mid-session because apparently ACP doesn't send aconfig_option_updatewhen the model changes directly viasession/set_model.I'm sure I'll keep finding a need for hooks into the other calls too. I feel like I'm playing whackamole with adding new hooks and don't feel like it should require a new PR every time a new ACP method is added. That's probably annoying for everyone.
So I was thinking about it and maybe the best path for hooks would be to pass them into the
ACPClientand invoke hooks in ACPClient:_send_request and just identify hooks by their method name?There could be a generic hooks that runs before the request, and another that runs after. As new ACP methods are added, no new code would be needed, as it's all handled directly at the client level when the requests are being made.
This could also be done for notifications at ACPClient._handle_notification which could invoke hooks based on the method. For non-notification messages, the
posthook on the original request would be called.Perhaps something like this:
Perhaps something sort of like this main...chancez:agentic.nvim:pr/chancez/acp_hooks. I haven't tested it, just putting it up as an example of what I'm thinking.