Add Icons to model and adapter selector to indicate capabilities

[kwibus]

Description

Adds icons to the selection dialog of adapters and models. So user can get a indication what the support.

Related Issue(s)

Have not yet create a issue for this.
But the idea for this was triggered when working on #2246 (edit: refered to the wrong mistral merge request before)

Consider this merge request more as a issue.
If you don't like the idea for now. Ore rather work on it yourself, you can close this pull request.
But i create a working prototype already, so why not send it.

Screenshots

select adapter

select model

Checklist

• I've read the contributing guidelines and have adhered to them in this PR
• I've added test coverage for this fix/feature
• I've run make all to ensure docs are generated, tests pass and my formatting is applied
• (optional) I've updated CodeCompanion.has in the init.lua file for my new feature
• (optional) I've updated the README and/or relevant docs pages

[olimorris]

This will be AMAZING! Totally up for this. Most users will have a nerdfont so I think some sensible defaults could be chosen from here.

[kwibus]

I have changed the icons used. But i had a hard time picking a icon from nerd-font that:

• readable when small
• clear what it means, and can't confused for something else.

I picked

• tools: nf-cod-tools. might be confused. for setting. but from context i think it's clear.

• vision: nf-md-image_plus. Eye icon would also work to. But might not be clear what it means. Other tools sometime use paperclip as attachment icon. But i think vision. only indicates reading image files. not other types of attachments.

• stream: nf-fa-arrow_right_arrow_left. is think most unclear. but could not find a better one. maybe nf-cod-live_share

• reason: nf-md-thought_bubble_outline. think it clear. nf-md-chat_processing_outline is other option

This list of icons i have looked at: icons.md

[kwibus]

I have some question:

• This plug kind of assumes that Adapter.opts.tool == true before setup is called, means the adapter support tool calling. So at least 1 model of the adapter supports it?

  • Not that the default model support tool calling.
  • Not that models support tool calling as a default
    Same for other capabilities.
    I might misunderstand this. Or it did not matter until now?

• Currently no adapter has opts.reason. Because it's always set per model.
  Shall I set opts.reason for models where some models support it?

• Before, there was no code outside the code for the adapter that shared what is inside the model.opts
  This pull request make is more important that all adapters use the same fields.
  not a mix of can_use_tools and has_function_calling`.
  Most adapter already uses the same fields, I can make them the same. Is this oke?

• I think about adding type annotation for model.opts and adapter.opts.
  But that makes this merge request lot more complicated and big. So might be better to do that in separate merge request?

• Getting the complete set of capabilities to show up currently for models is hard.
  It depends on how adapter.setup (adapter.lifecycle.setup) is implemented.
  For example:

  In some adapter, setup does not modify stream. So all models "inherit" can_stream.
  So if you want to see this in the select menu, you want to include this.

  But counter example where this is not the case is vision.
  For most adapter that support vision. It seems that the adapter has opt.vision == true but this is not "inherited"
  Setup set it only if the model.opts says it supports vision.

  There are lots of ways to solve this. Some are:

  • ignore for now: icons are close enough
  • I can update so model.opts is always complete, and we don't have to rely on "inheritance"
  • We can say. vision is inherited, but other capabilities not?
  • If none of the models species it can do it. Then it's inherited from adapter.

• Does this need a test? If so i would like to refactor M.change_adapter a bit. EDIT after your recent changes of M.change_adapter It would be easy to add test

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[kwibus]

I have update merge request, so it works's with new M.change_adapter.
Are you still interested?

If so. Then I still don't know what to say of a model or adapter capabilities If not set. As I asked before.
What I have now works. But is not sometimes incomplete.