Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: improved dynamic_command support #193

Open
1 task done
jfly opened this issue Oct 11, 2024 · 0 comments
Open
1 task done

Feature request: improved dynamic_command support #193

jfly opened this issue Oct 11, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@jfly
Copy link
Collaborator

jfly commented Oct 11, 2024

Issues

  • 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.
@jfly jfly added the enhancement New feature or request label Oct 11, 2024
jfly added a commit that referenced this issue Oct 11, 2024
…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.
@jfly jfly self-assigned this Oct 11, 2024
jfly added a commit to jfly/none-ls.nvim that referenced this issue Oct 11, 2024
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant