This is too special-case and the use-case is not explained.

vim.lsp.buf.code_action() , typically shows a menu. I don't see why you wouldn't want a tiny "no actions available" message if there are no actions available, since invoking vim.lsp.buf.code_action() explicitly is asking for some sort of feedback.

With #22598 one can use this hack to clear the screen after code_action():

lua vim.func.on_fun(vim.lsp.buf, 'code_action', function()
    vim.cmd[[call timer_start(100, {->luaeval('print(" ")')})]]
end)

A more ideal approach would be for vim.lsp.buf.code_action() to return a promise as @mfussenegger described in that PR discussion. Then one could do something like:

lua vim.func.on_fun(vim.lsp.buf, 'code_action', function(fn, args)
    local promise = fn(unpack(args))
    promise.then(function()
        vim.cmd.redraw()  -- or some other way to clear the screen
    end)
end)

I already notice that pr. but what i mean in this pr. when you set the apply = true in code action it will execute the first actions. like if you config this in BufWritePre with import actions. if no actions it will show this notify. maybe pr as a temporary solutions ...support silent in autocmd is useful.

As mentioned, too special-case. Perhaps all of these LSP features should accept something like a on_done or on_after callback to address all of these use-cases. But as described in #22598 (comment) , ideally would be more like :

1. Have some kind of future/promise/async-thunk/whatever (relates a bit to Lua: structured concurrency, Promises, task pipelines #19624) that each of the vim.lsp.buf methods returns that allows to
   a) cancel
   b) use the synthesized result of the operation by being able to attach an additional callback or map the result. This would address feat(lsp): return result of buf_request() in LSP functions #18372 and lots of other feature requests.
   c) await (coroutine aware) or get(blocking) the result.

I already have some local version where I played around with this a bit. There I also have a new vim.lsp.request that would replace buf_request, buf_request_all and buf_request_sync and also solve the mixed-encoding warnings.

2. Maybe add a LspResponse autocmd that's triggered whenever a response is received with data set to the payload as a generic listener mechanism.

The short-term solution could be to add LspResponse.

looks useful ? not sure. when there have this pr i will take a look at this. currently refactor pmenu now .