-
Notifications
You must be signed in to change notification settings - Fork 460
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
feat: inlay hints for auto-implicits #6768
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mathlib CI status (docs):
|
Kha
approved these changes
Feb 4, 2025
Julian
added a commit
to Julian/lean.nvim
that referenced
this pull request
Feb 5, 2025
leanprover/lean4#6768 is now merged (hooray!) and means that Lean shows useful information like the use of auto-implicits via inlay hints. This functionality is already available on Lean4 HEAD, and will shortly be available in nightlies (and then in a release candidate). Note that Neovim does not enable them by default, but this is mostly because exactly what is shown in inlay hints varies widely by language -- and here, it seems more reasonable that they be enabled by default in Lean. We do so only buffer-locally, and users can opt out of this by setting `enabled = false` in the new `inlay_hint` config table. (This also shouldn't interfere if any user is calling `vim.lsp.inlay_hint.enable()` themselves already).
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 6, 2025
This PR implements a number of refinements for the auto-implicit inlay hints implemented in #6768. Specifically: - In #6768, there was a bug where the inlay hint edit delay could accumulate on successive edits, which meant that it could sometimes take much longer for inlay hints to show up. This PR implements the basic infrastructure for request cancellation and implements request cancellation for semantic tokens and inlay hints to resolve the issue. With this edit delay bug fixed, it made more sense to increase the edit delay slightly from 2000ms to 3000ms. - In #6768, we applied the edit delay to every single inlay hint request in order to reduce the amount of inlay hint flickering. This meant that the edit delay also had a significant effect on how far inlay hints would lag behind the file progress bar. This PR adjusts the edit delay logic so that it only affects requests sent directly after a corresponding `didChange` notification. Once the edit delay is used up, all further semantic token requests are responded to without delay, so that the only latency that affects how far the inlay hints lag behind the progress bar is how often we emit refresh requests and how long VS Code takes to respond to them. - For inlay hints, refresh requests are now emitted 500ms after a response to an inlay hint request, not 2000ms, which means that after the edit delay, inlay hints should only lag behind the progress bar by about up to 500ms. This is justifiable for inlay hints because the response should be much smaller than e.g. is the case for semantic tokens. - In #6768, 'Restart File' did not prompt a refresh, but it does now. - VS Code does not immediately remove old inlay hints from the document when they are applied. In #6768, this meant that inlay hints would linger around for a bit once applied. To mitigate this issue, this PR adjusts the inlay hint edit delay logic to identify edits sent from the client as being inlay hint applications, and sets the edit delay to 0ms for the inlay hint requests following it. This means that inlay hints are now applied immediately. - In #6768, hovering over single-letter auto-implicit inlay hints was a bit finicky because VS Code uses the regular cursor icon on inlay hints, not the thin text cursor icon, which means that it is easy to put the cursor in the wrong spot. We now add the separation character (` ` or `{`) preceding an auto-implicit to the hover range as well, which makes hovering over inlay hints much smoother.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
changelog-server
Language server, widgets, and IDE extensions
toolchain-available
A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds preliminary support for inlay hints, as well as support for inlay hints that denote the auto-implicits of a function. Hovering over an auto-implicit displays its type and double-clicking the auto-implicit inserts it into the text document.
This PR is an extension of #3910.
Known issues
textDocument/inlayHint/resolve
request yet. Implementing support for this request is future work.Other changes
textDocument/didChange
), so this PR introduces the notion of a stateful LSP request handler.example
had the full declaration as its (non-canonical synthetic) range. Since we need a reasonable position for the identifier to insert an inlay hint for the auto-implicits of anexample
, we change the (canonical synthetic) range of the synthetic identifier to that of theexample
keyword.Breaking changes
chainLspRequestHandler
function must now use thechainStatefulLspRequestHandler
function instead.