You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have checked existing issues and there are no existing ones with the same request.
Feature description
While working on #192, I learned about none-ls's dynamic_command functionality, which I understand is often paired with the by_bufnr cache helper. This works great, but it does mean the very first time I save a buffer, I have to wait for my dynamic_command to generate the command. After that point, things are cached, and life is great. I think things could be even better, though:
I'd like have none-ls to start computing the dynamic_command the moment I open a buffer. Since I usually spend some time reading a file before making a change, I expect this to make the dynamic_command delay disappear in practice (by the time I make a change and try to format my buffer, we'll have already computed the dynamic_command.
Help
Yes
Implementation help
I'd be happy to implement this.
Is this setup_buffer function the right place to trigger the dynamic_command lookup?
Rather than adding a new option for this, I'd like to just enable this for all formatters with a dynamic_command that uses a cache helper. Right now, I don't think it's possible to check if a dynamic_command uses a cache helper, but I think we could achieve that by reworking our cache helper function to return a "callable table".
I'd then rework the code that currently invokes dynamic_command to instead wait for any ongoing dynamic_commands to finish so we don't trigger a second one while the original one is going. Conveniently, it doesn't actually matter how many ongoing dynamic_commands there are, we just need to wait for them to finish, and then we can invoke dynamic_command knowing we'll get an instantaneous response.
Bonus points: I think we could give the user a slick progress notifcation using LSP's Progress Support, which I learned about from https://github.com/j-hui/fidget.nvim. Basically, we can give a progress bar/spinner while we're invoking the dynamic_command for the current buffer.
The text was updated successfully, but these errors were encountered:
…ening buffers
This implements <#193>.
This is incomplete: I've redefined `dynamic_command` to be an async
function, but I haven't actually updated all the builtins accordingly. I
have updated `nix_flake_fmt` to demonstrate the idea.
If folks like the direction I'm going with this, I'll polish up
the PR so all `dynamic_command`s are async, and I'll get the tests
passing.
…ening buffers
This implements <nvimtools#193>.
This is incomplete: I've redefined `dynamic_command` to be an async
function, but I haven't actually updated all the builtins accordingly. I
have updated `nix_flake_fmt` to demonstrate the idea.
If folks like the direction I'm going with this, I'll polish up
the PR so all `dynamic_command`s are async, and I'll get the tests
passing.
Issues
Feature description
While working on #192, I learned about none-ls's
dynamic_command
functionality, which I understand is often paired with theby_bufnr
cache helper. This works great, but it does mean the very first time I save a buffer, I have to wait for mydynamic_command
to generate the command. After that point, things are cached, and life is great. I think things could be even better, though:I'd like have none-ls to start computing the
dynamic_command
the moment I open a buffer. Since I usually spend some time reading a file before making a change, I expect this to make the dynamic_command delay disappear in practice (by the time I make a change and try to format my buffer, we'll have already computed thedynamic_command
.Help
Yes
Implementation help
I'd be happy to implement this.
setup_buffer
function the right place to trigger thedynamic_command
lookup?dynamic_command
that uses a cache helper. Right now, I don't think it's possible to check if adynamic_command
uses a cache helper, but I think we could achieve that by reworking our cache helper function to return a "callable table".dynamic_command
to instead wait for any ongoingdynamic_command
s to finish so we don't trigger a second one while the original one is going. Conveniently, it doesn't actually matter how many ongoingdynamic_commands
there are, we just need to wait for them to finish, and then we can invokedynamic_command
knowing we'll get an instantaneous response.dynamic_command
for the current buffer.The text was updated successfully, but these errors were encountered: