feat(lualine): add spinner component

[nguquen]

• fire events: MinuetRequestStarted and MinuetRequestFinished when job started & finished
• add lualine component to show a spinner

Usage:

-- lualine
require('lualine').setup({
  sections = {
    lualine_x = {
      require('minuet.lualine'),
      'encoding',
      'fileformat',
      'filetype',
    },
  }
})

[milanglacier]

Thanks for contributing to minuet!

I like the idea of adding the two user events MinuetRequestStarted and MinuetRequestFinished,

I want to note that for openai_fim_compatible provider, multiple requests can be launched simultaneously (depending on n_completions).

As such, you may face the race conditions that MinuetRequestFinished fired while there are still other unfinished requests.

So instead of launching the MinuetRequest* event in common.register_jobs and common.remove_job, I think we want to fire those events inside each provider's complete function. (aka common.compete_openai_base, common.complete_openai_fim_base, claude.complete, and gemini.complete)

For each MinuetRequest* , I want to provide the following options (passed by opts.data in nvim_exec_autocmds):

{
    provider = "openai_compatible", -- or others
    name = "fireworks", -- or others, specified from provider_options
    n_requests = 3, -- depending on how many jobs are launched
    request_idx = 1, -- the request idx out of n_requests
    job = job -- the plenary job itself,
}

I want to note that for openai_fim_compatible provider, multiple requests can be launched simultaneously (depending on n_completions).

This also makes implementing the lualine spinner trickier, as I think we need to add an indexer to indicates how many requests are completed (something like 1/2 or 1/3 if there are more than 1 requests launched simultaneously).

Thanks.

[nguquen]

@milanglacier i've changed code based on your feedback, except we cannot pass the job itself to user event.

[nguquen]

@milanglacier could you help to review again?

[milanglacier]

Hi, sorry for the late reply.

I was working on the new feature (in-process LSP) recently and don't have time to review the code.

[milanglacier]

Can you also fire those events for Gemini and Claude. The related code are located under minuet/backends/claude.lua and minuet/backends/gemini.lua

Beside you can pass job itself to the event, like this:

1. For finished event, In on_exit function, note that job is part of the function parameter. Just pass job to the autocmd event.
2. For init event, you can fire the event after new_job:start(), and you can just pass new_job to the event.

Thanks!

[nguquen]

@milanglacier i've fired those events for Gemini & Claude backends.

for passing the job, i know where to pass it, but looks like we cannot pass the job directly to user event, here's the error i got:

E5108: Error executing lua: ...te/pack/packer/start/minuet-ai.nvim/lua/minuet/utils.lua:494: Invalid 'data': Cannot convert use
rdata
stack traceback:
        [C]: in function 'nvim_exec_autocmds'

[milanglacier]

thanks for the update. It seems like this is a lua <-> vimscript interop issue?

can you try to wrap the job inside a function and see if it works?

something like this function() return job end, and try to access the job in and event and see if it works.

[nguquen]

@milanglacier wrapping the job inside a function works 👍 , i've updated the code.

[milanglacier]

thanks for update.

the code looks okay to me.

I will pull your branch to local and test it for a while. Once it works fine on my local, and I can merge it.

[milanglacier]

Thanks for the updates. I will merge this to a dev branch, and make some updates including README and some tiny tweak like names, then will merge it to main.

[milanglacier]

I have merged it into the main branch.

There are a few updates:

1. I renamed the MinuetRequestInit to MinuetRequestStartedPre, as this name can indicate the difference with minuetRequestStarted clearer.
2. I added a new datafield timestamp which is the time when MinuetRequestStartPre event emit.
3. I removed the job field. Sorry again for that you have spent so many time on this and I decided to remove this field in the last minute. I just feel that wrapping the job inside a function is not really elegant. In the future we can figure out a better way to provide the job information if there's a need for it.

Thanks again for contribution!