Composable transient sub-menus

[karthink]

Re: your potential plan to add transient menus to evedel:

Turns out it's really simple to define reusable Transient sub-menus/groups. I can make gptel's main Transient menu more composable so you may be able to reuse just the groups you need for setting model parameters etc, without having to reimplement them from scratch.

Of course, if you only need a couple of Transient suffixes (the one for setting the gptel-backend/model, say) you can just call them directly in your menu as well.

Let me know if this is something you're interested in.

PS: You may want to open the discussions page for this repo for topics like this one.

[daedsidog]

Thanks for looking into that.

The interaction with overlays itself is pretty rudimentary at this point, and I don't foresee it getting much too complication. Besides, I loved your help-echo idea. I was thinking to "embed" tool-tips and controls of this nature to the overlay layer.

One thing that I really want to see in the future is integration with the chat buffer, so that means interacting with the chat buffer's menu. I'm not creative enough to see how I would like this done. I could use the existing gptel context options to determine if my contexts should be embedded into queries, though I think it's better that I have my own separate suffix for this.

I would probably want two options: something binary that lets me choose whether to use references in the chat or not (basically the same for the gptel contexts), and something that lets me input a tag query to filter which references to use by tag.

I am also planning to make a feature which, in addition to having buffer references, will allow me to have "window" references. So, you mark a "window" as part of the reference, and when the request is sent, you send the region of the buffer currently presented in the viewport, essentially giving the AI a "look" into how your Emacs looks. This takes up very little context and essentially gives the AI live "eyes" on your Emacs, so would be able to do things like "fix this code until all these tests pass!" and he should be able to understand without too much trouble, assuming you're watching them as well.

I'm conflicted if it's worthwhile considering images basically do the same thing, just as a higher cost.

EDIT: Opened discussions tab.

[karthink]

Besides, I loved your help-echo idea. I was thinking to "embed" tool-tips and controls of this nature to the overlay layer.

Have you looked at or tried out gptel's new rewrite system yet? Here are a couple of screenshots: by default, it just highlights the region being rewritten, and you can choose how you want to apply/compare changes. Besides help-echo, it shows available actions using Eldoc when point is inside the overlay.

And the menu options apply to all overlays in the buffer:

[karthink]

One thing that I really want to see in the future is integration with the chat buffer, so that means interacting with the chat buffer's menu. I'm not creative enough to see how I would like this done. I could use the existing gptel context options to determine if my contexts should be embedded into queries, though I think it's better that I have my own separate suffix for this.

Have you checked out Elysium? I haven't yet, but they're doing something involving integrating gptel's chat buffer to make changes to files.

I am also planning to make a feature which, in addition to having buffer references, will allow me to have "window" references. So, you mark a "window" as part of the reference, and when the request is sent, you send the region of the buffer currently presented in the viewport, essentially giving the AI a "look" into how your Emacs looks. This takes up very little context and essentially gives the AI live "eyes" on your Emacs, so would be able to do things like "fix this code until all these tests pass!" and he should be able to understand without too much trouble, assuming you're watching them as well.

This is a neat idea!

I'm conflicted if it's worthwhile considering images basically do the same thing, just as a higher cost.

Sending the window text is simpler and easier, I think. You can support more models this way too, only the flagship models have multi-modal (images etc) support.

EDIT: Speaking of images, adding image and function calling support to gptel backends is the next task on my list. Now that there are a couple of projects like this one working on UI experiments, adding more advanced UI features to gptel is unnecessary. Focusing on improving gptel-request will help more.