Document code uses task.selectionRange, but we only ask the LLM to produce documentation, not the code within the range.
This has some benefits:
It's faster, we don't have to wait for the rest of the code to be repeated
It's more reliable, we only want the LLM to get the docstring right, not anything else.
But we introduce some problems with this method:
Cannot easily calculate decorations, as the selectionRange doesn't match what we're actually inserting.
Retry is buggy, as it'll undo the entire selection range
More?
Expected behavior
We need some range to provide to the LLM, we should propose a way for a task to have a separate contextRange (or similar) to the selectionRange.
For document code, this means we could have asmall selection range (empty at first) that grows as the documentation is added. This will mean that decorations, retry behaviour and anything else should just work as normal. We can still use contextRange to provide the correct code (that we want documented) to the LLM.
Version
Latest
mainDescribe the bug
Document code uses
task.selectionRange, but we only ask the LLM to produce documentation, not the code within the range.This has some benefits:
But we introduce some problems with this method:
Expected behavior
We need some range to provide to the LLM, we should propose a way for a task to have a separate
contextRange(or similar) to theselectionRange.For document code, this means we could have asmall selection range (empty at first) that grows as the documentation is added. This will mean that decorations, retry behaviour and anything else should just work as normal. We can still use
contextRangeto provide the correct code (that we want documented) to the LLM.Additional context
No response