Codeium functionality

[C-Loftus]

Adds very basic functionality to use Codium. This is a free alternative to copilot. It is less feature rich but still generally good.

@pokey curious if you have any ideas or opinions. (i.e. is this worth adding or just bloat, any other offline copilot tools that might be worth adding, etc.) Wanted to check since you made the copilot commands and Codium is very similar. Wasn't sure to what extent you still use them, or if you think this is useful.

I was waiting to add the cursorless support for codeium since I am not sure how useful this is

[C-Loftus]

@jaresty also, curious do you think https://continue.dev should be added to the ai-tools repo? Seems like it might belong in this PR, although I wasn't sure since I haven't used it and not sure if it is hard to setup or out of scope

[jaresty]

I think that's a great idea. I could use some help with word smithing the name. "Continue" is a key word so I've been trying to come up with good alternatives. I do think it would make sense to include here. This points to where I've configured it in my repo: https://github.com/jaresty/mac-dotfiles/commit/6fdb0bbdf0b6320eb9497a7eba882387a068348d

[C-Loftus]

I think that's a great idea. I could use some help with word smithing the name. "Continue" is a key word so I've been trying to come up with good alternatives. I do think it would make sense to include here. This points to where I've configured it in my repo: jaresty/mac-dotfiles@6fdb0bb

That makes sense. I will think about this but yeah I am not sure either at the moment since continue is rather generic. Something to abbreviate it like tin you X honestly could be an option

[jaresty]

Yeah, I like that! Please feel free to pull in my stuff and use that name if you like. I'm away for the weekend so can't test it out but I expect it'll work just fine.

[C-Loftus]

Yeah, I like that! Please feel free to pull in my stuff and use that name if you like. I'm away for the weekend so can't test it out but I expect it'll work just fine.

Make sense, when I get some time I will move some of it over. I wonder if pokey has opinions on how to structure this in terms of context matching. Since as well we could just use pilot for all 3, and then have some sort of tag that is updated based on which extension is installed and running in visual studio code. since I don't think people would be running multiple at once

[jaresty]

I could imagine using both pilot and continue while I try them out before I decide which one I prefer, or if I learn that one is better for a certain type of problem.

[C-Loftus]

I could imagine using both pilot and continue while I try them out before I decide which one I prefer, or if I learn that one is better for a certain type of problem.

I think what I was moreso getting at is the fact we could eventually condense all these commands into the same file and just use pilot as the keyword namespace for all. And then contextually we would either send the command as a continue copilot or codeium command depending on which addon was enabled. Since I don't think anyone is using multiple at once.

Right now they are all separated. Please let me know if those continue commands work.

[jaresty]

yeah-I understood that. I'm thinking though that there's still a benefit to having more than one available since the space is evolving so quickly. While there is some overlap, I'm still not sure that I could settle on one or the other and may want to switch between them throughout the day. If we're concerned about the overlap maybe we could use a tag to enable or disable the ones that you want.

[jaresty]

I've added a couple more here. I'm also not sure the best way to handle this but these cursorless custom actions are really important to my workflow. I'm not aware of a good way to incorporate the custom CSV though.

[C-Loftus]

yeah-I understood that. I'm thinking though that there's still a benefit to having more than one available since the space is evolving so quickly. While there is some overlap, I'm still not sure that I could settle on one or the other and may want to switch between them throughout the day. If we're concerned about the overlap maybe we could use a tag to enable or disable the ones that you want.

Sure that's fine. I was thinking as well that it makes sense to keep them separate and not worry about overlap until things are stabilized more.

I've added a couple more here. I'm also not sure the best way to handle this but these cursorless custom actions are really important to my workflow. I'm not aware of a good way to incorporate the custom CSV though.

Cool sounds good. Feel free to add what you want into this PR. Maybe before we merge you could test and make sure the ones in this repo are working as intended.

With regards to custom cursorless actions, Id just keep those in your personal config. I don't think it is possible to easily share individual ones at the moment

[jaresty]

I added some additional helpers and tested them out. Everything seems to be working from what I can tell

[C-Loftus]

Awesome thank you !! I will continue testing the codeium functionality and then merge once I am happy with it at a baseline. (Any other more sophisticated features in other future PRs most likely)

[jaresty]

I borrowed the cursorless strategy from the pilot implementation

[C-Loftus]

I would definitely lean towards having a single command set whose implementation changes based on a tag. I can see your argument about trying multiple at once, but long-term I think that's going to be bad for muscle memory. We could add a way to force one or the other with a slightly longer command that can be used in addition, but I think we want one set of compact commands that allows you to switch to another autocomplete engine without breaking your muscle memory

Yeah that makes sense and I agree. I think the main issue is there I am not sure how to set the tag based on whether a vscode extension is running. I am sure there is a way to do it, just a bit swamped atm

Regardless, I have been using codeium a fair bit at the moment as well and I am not sure if I even like it enough to even support it here. It is much worse than copilot.

[pokey]

No I don't think we can set it based on whether extension is running, nor would we want to. The user might have both installed. The user should set the setting direclty in settings.talon like we do with other tags that function as a form of configuration

[jaresty]

I would definitely lean towards having a single command set whose implementation changes based on a tag.

I generally think this is a nice idea, but I am concerned that there are cases where you will not be able to completely replace one with another. I definitely want to be able to use both model commands and continue commands at the same time because they have different purposes in my workflow. I'm less convinced about the need to use both copilot and continue concurrently. I probably would have kept using copilot if I still had access but I had to switch to continue because I had no choice though it's working just fine for me.

[C-Loftus]

I definitely want to be able to use both model commands and continue commands at the same time because they have different purposes in my workflow

Do you mean copilot and continue? I think Pokey is just saying a tag for each copilot-esque feature. None of these should interact with the model (i.e. gpt) commands.

i.e To my understanding Pokey is saying to have three tags like the following that a user can enable

• provider_github
• provider_codeium
• provider_continue

And then have them all use a similar command that just gets overridden contextually

Only thing I don't love about this is that having three separate tags

[jaresty]

If that's what he means then yeah I think that's fine!

[jaresty]

One thing I did run into-continue doesn't work with the same completion commands that our pilot integration uses for suggest and cancel. I had to implement cancel as just an escape key. There didn't seem to be a way to get the next suggestion that I found.

[C-Loftus]

Made some edits. Moved continue.talon into gpt-beta for the time being. @jaresty when you get a chance perhaps you could submit a PR against that file. I can't really test it and wasn't sure what you prefer. Perhaps you could remove the commands you said don't work. I moved the gpt-setttings into the root now that we have a tag.

I added a tag for copilot but not for continue since they theoretically might be able to be used together and continue is in beta still until we figure out syntax. I also made it so the codeium and copilot commands have the same baseline syntax. Didn't add cursorless stuff to codeium. That is perhaps for a future PR

[jaresty]

I already removed the broken commands a while back. Everything was working last I checked. It is working well for me.

[C-Loftus]

I already removed the broken commands a while back. Everything was working last I checked. It is working well for me.

Ok great! So is everything good as it is now in this PR? Just wanted to clarify if when you say that you mean in this PR, not your local repo

[jaresty]

Yep!

[pokey]

No I meant a tag that can take one of three values: codeium, copilot, or continue. Then there's one talon file that defines the spoken grammar, mapping to actions. The implementation of these actions varies based on the value of the tag, by using a context for each one (in Python).

However, I now realise that wouldn't work exactly, because a tag is just a Boolean flag, so can't take three different values. A setting or a scope would probably be better

The problem with this PR as merged is the duplication of spoken forms. Means you have to change multiple places, and you end up with conflicts if you have multiple tags on

I would argue for the subset of commands that overlaps between the three to be defined in one file. The commands unique to each service would then be in separate files. Those files could also contain more specific commands you could use to trigger that model specifically instead of the default model you've chosen

[C-Loftus]

Currently I just have one tag, namely to use codeium. By matching on this or the logical not of the tag, the two sets of pilot commands are mutually exclusive. The continue commands are within the beta folder since they may change and could theoretically be used alongside copilot.

If you use one file and just change the implementation within python, then I think it is confusing to the user what commands are supported by the current pilot implementation. Since the codeium feature set is quite a bit smaller.

I agree that you end up having to change things in multiple places. But since the amount of command supported is relatively small, I think it is OK and makes it super clear what is supported by codeium.

When I add cursorless support for codeium in a future PR I will probably refactor as you say so we don’t duplicate that.

Let me know if this sounds reasonable (I will be at the cursorless meetup tomorrow if you want to just chat there too)

On Sat, Apr 6, 2024 at 5:12 AM Pokey Rule @.***> wrote:

No I meant a tag that can take one of three values: codeium, copilot, or continue. Then there's one talon file that defines the spoken grammar, mapping to actions. The implementation of these actions varies based on the value of the tag, by using a context for each one (in Python).

However, I now realise that wouldn't work exactly, because a tag is just a Boolean flag, so can't take three different values. A setting or a scope would probably be better

The problem with this PR as merged is the duplication of spoken forms. Means you have to change multiple places, and you end up with conflicts if you have multiple tags on

I would argue for the subset of commands that overlaps between the three to be defined in one file. The commands unique to each service would then be in separate files. Those files could also contain more specific commands you could use to trigger that model specifically instead of the default model you've chosen

— Reply to this email directly, view it on GitHub https://github.com/C-Loftus/talon-ai-tools/pull/46#issuecomment-2041025877, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQ2T6Z7ZTBVGDXB6S6DYRQTY3635DAVCNFSM6AAAAABFFB6RYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGAZDKOBXG4 . You are receiving this because you modified the open/close state.Message ID: @.***>

[pokey]

Sure maybe let's just do a quick run through at cursorless meetup

[jaresty]

Just checking-there isn't a proposal here that would require users to edit this repository, right? I don't think so, but that's one thing I'm hoping to avoid.

[C-Loftus]

Nope don’t believe so. I agree I don’t want that. Going forward generally I am never going to merge something that requires editing the repo in place/forking since I think it’s an anti pattern.

On Sat, Apr 6, 2024 at 11:35 AM Schwa Aresty @.***> wrote:

Just checking-there isn't a proposal here that would require users to edit this repository, right? I don't think so, but that's one thing I'm hoping to avoid.

— Reply to this email directly, view it on GitHub https://github.com/C-Loftus/talon-ai-tools/pull/46#issuecomment-2041119980, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQ2T6Z4FPTGF46OH7QFYVILY4AIZNAVCNFSM6AAAAABFFB6RYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGEYTSOJYGA . You are receiving this because you modified the open/close state.Message ID: @.***>

[C-Loftus]

Talked with Pokey today. This will be left as is for now until I add other copilot providers / move continue out beta once I have more time to test.

Going forward we will eventually split this into a format like the following where there is a central set of commands and then specific ones for each provider that are mutual exclusive with the other providers.

pilot.talon
codeium.talon
github_copilot.talon
$OTHER_PROVIDER.talon

To match on which provider is context matched, we will use a scope most likely. But we need to check if we can use a talon setting to update a scope for matching since we cannot match on a setting directly