@U04V15CAJ Thoughts on this ^ Want to know if it's worth solving or if it's a can of worms for tools like kondo

@U8WFYMFRU p/catch already exists in promesa. how would you re-use it for this macro?

In kitchen-async they introduce a separate name (which was going to be my strategy too) . The way they set it up was that there was p/catch for p/try and p/catch* for promise.catch. Was thinking on reversing that so promesa.catch* would be the counterpart to promesa.try. But it seems like getting p/try working and using lint-as might create more problems given that kondo is throwing an error that there is no catch statement in there

So if it's not too much trouble in kondo (willing to help with the PR) then I'll continue with the promesa PR, but if it just creates more problems then it may not be worth implementing

there's always a way to support this in clj-kondo via hooks

it even has support for better-cond via custom hooks which is quite complicated

so there's no reason to restrain yourself here

I see so I can start out with using hooks in my userland config, then can include it in the promesa config when I'm ready for that upstream PR?

yeah

That works, thanks once again for your insight!