Embark actions for pods

[jinnovation]

Can start with a map that only binds kele-get. This would be a little contrived, since kele-get is the only resource-related command at the moment, but it'd give us a springboard to start implementing and binding other pod-related functionality, e.g. fetching and following logs.

[ashlineldridge]

This is a great idea. I really like the direction this project is going! An Embark action for port-forwarding would be another good use-case. At the moment, Embark seems to consider Kele completion candidates as a generic identifier and so you get the default action keymap. If I understand how this works, if you could categorize the resource candidates with their own symbol then people could start writing their own Embark actions by adding to embark-keymap-alist?

[jinnovation]

If I understand how this works, if you could categorize the resource candidates with their own symbol then people could start writing their own Embark actions by adding to embark-keymap-alist?

Absolutely. I haven't had the chance to explore this in-depth, but my thinking is very aligned w/ your idea here. Basically:

1. Associate resource candidates with symbols corresponding to their kind, e.g. kele-pod or kele-customresourcedefinition;
2. Provide a handful of starter Embark actions for select kinds;
3. Provide convenient hook mechanisms for users to write their own kind-specific Embark actions (as you describe)

[jinnovation]

Deprioritizing Embark integrations in favor of fleshing out Transient-based usage first. Transient is in core Emacs while Embark is not, which means that improvements we make to Transient usage will have broader reach and appeal.

[jinnovation]

In this particular case, I suspect we'll be able to reap much of the same benefits of specialized Embark keymaps with resource-specific suffixes on kele-resource -- a pattern we introduced in #187.