Do not call vim.notify in set_target_arch by default

[MarkusPettersson98]

This PR updates set_target_arch to not call vim.notify internally. Instead this is moved to the more imperative :RustAnalyzer target command by default, which is made possible because set_target_arch is made a bit more flexible by providing a callback hook for when the target has been updated.

My motivation for doing this is that I wrap set_target_arch as part of another command in my neovim config, and I have other means of formatting & showing the currently selected rust-analyzer target than the currently enforced style of rustaceanvims set_target_arch. I still think it makes sense to provide the feedback whether the target update was successful or not when the :RustAnalyzer target command is invoked manually.

Thanks 💛

[github-actions]

Review Checklist

Does this PR follow the Contribution Guidelines? Following is a partial checklist:

Proper conventional commit scoping:

• For example, fix(lsp): some lsp-related bugfix

• Pull request title has the appropriate conventional commit prefix.

If applicable:

• Tested
  • Tests have been added.
  • Tested manually (Steps to reproduce in PR description).
• Updated documentation.

[mrcjkb]

hey 👋

Thanks for the PR.
rustaceanvim does not expose a public Lua API. I may change or remove Lua functions without a major version bump, so I don't recommend you use internal Lua modules directly in your config.

What exactly is your use case? Perhaps we can find a better solution?

I think the info log message may be redundant, because rust-analyzer should provide feedback about rebuilding, which you can see if you use something like fidget.nvim.

[MarkusPettersson98]

Aight, didn't mean to depend on internals willy nilly! I hope we're able to figure something out 😄

My use case is a bit two-fold. When I invoke rustaceanvim.lsp.set_target_arch I issue a custom notification using fidget

local set_rust_target = function(target) 
  require('fidget').notify('Switching rust-analyzer target => ' .. target)
  require('rustaceanvim.lsp').set_target_arch(nil, target)
end

As you said, rust-analyzer will information that it is rebuilding for a new target, but afaict it does not provide any feedback on which target this is? Please prove me wrong 😅

The second case is that I've created an autocommand to run on LspAttach which looks for the rust-analyzer target and updates my statusline

With all of this, it feels a bit overkill to have the target also be printed to the echo area 😊

Not depending on any private functions in this case is trivial

local set_rust_target = function(target)
  local fidget = require 'fidget'
  fidget.notify('Switching rust-analyzer target => ' .. target)
  vim.cmd(':RustAnalyzer target ' .. target)
end

But as is I will see the notifications that are issued by :RustAnalyzer target. I could probably make fidget show the output of :RustAnalyzer target, but this feedback would be a bit delayed as vim.notify is called after the lsp client has been restarted.. And it would be nice to still provide custom formatting for :RustAnalyzer target, or at least have an option to silence the command.

I see how all of these wants risk bloating your module, so feel free to close this PR if you don't like where I'm trying to go with this 😅

[mrcjkb]

I'm removing the info notification: 7a565dc. In fact, by the time it is emitted, there is no guarantee that switching the target architecture was successful, because the LSP client request is async.

[MarkusPettersson98]

Thanks, that'll do for my use case 😊