feat(vscode): support attach file context to inline edit

[zhanba]

Feature

• Support attach file context to inline edit [VSCode] Allow attaching file context to inline editor #2964
• demo: https://jam.dev/c/41e820ac-9f92-4736-b113-e21f8f9a7d39

Need help

• how we update prompt template to include file content

[zhanba]

@wsxiaoys we should update prompt template to include {{fileContext}} part. Can you guide me on that?

[icycodes]

Hi @zhanba, Thank you for the PR!

The current design is good, but I have some concerns.

Use the same or seperated quick pick widget

The current design use the same quick pick widget for input commands and selecting files, but

1. The quick pick widget auto-filters items by the current value. If we include both command list and file list in one quick pick list, all items need to be marked as alwaysShow to be visible, which may not be the ideal behavior of a quick pick widget.
2. The modal stack is not clear if we blend the quick pick widget. When the user triggers file selection, accepting (Enter or Click on item) will complete the file selection and continue the input command, but dismissing (Esc) will stop the input command instead of continue. By use a new quick pick widget for file selection, we can temporarily hide the command quick pick widget and show the file quick pick widget. Once it is hidden (by accept or dismiss), we update and show the command quick pick widget again to continue.

So, I suggest using a new quick pick for file selection with pushing modal stack.

How to trigger file selection

1. Using @:
   This keeps the UX consistent with the chat side panel. But, to achieve this in a quick pick widget, we need some tricky processing. Detecting whether the last character is @ to trigger should be good enough. However, there are some cons:
   • The @file is not highlighted to mark it includes a file context.
   • When the user moves the cursor and is not at the end and inputs something, the @ is not properly triggered.
2. Adding a button to trigger selecting files:
   This avoids a lot of tricky implementations but is not as convenient as using @.
3. Using a more customizable editor for inputting command:
   This should solve these problems in a cleaner way but requires a side view instead of using the quick pick widget.

I suggest keeping plan 1 for now.

The resolved data interface for the promise of showQuickPick

I think the @file should be kept in the command, as it can be part of a command. For example:
A command could be Fix the use of function foo according to @foo.ts, where @foo.ts is included by selecting a file. Then the promise of showQuickPick should resolve as:

{
   "command": "Fix the use of function foo according to @foo.ts",
   "fileContexts": [{
      "referer": "@foo.ts",
      "uri": "file://path/to/foo.ts"
   }]
}

---

Let me know if you have any thoughts about these points.
Also cc @wsxiaoys for design review.

[zhanba]

@icycodes thanks for your reply with so many details!

The quick pick widget auto-filters items by the current value. If we include both command list and file list in one quick pick list, all items need to be marked as alwaysShow to be visible, which may not be the ideal behavior of a quick pick widget.

Use alwaysShow and filter items by ourself is acceptable, the problem is that we can't handle the sort of items, so the order of items may be inconsistent in a few case.

The modal stack is not clear if we blend the quick pick widget. When the user triggers file selection, accepting (Enter or Click on item) will complete the file selection and continue the input command, but dismissing (Esc) will stop the input command instead of continue. By use a new quick pick widget for file selection, we can temporarily hide the command quick pick widget and show the file quick pick widget. Once it is hidden (by accept or dismiss), we update and show the command quick pick widget again to continue.

I'm not sure if esc on file selection stop input would make real trouble for user. By using two quick pick, we can avoid this problem. My concern for two quick pick is that this may interrupt the user input and cause some context switch between two input which may confusing user.

On How to trigger file selection, I'm agree with you. Using @ is convenient but with some limitation due to the limited capability of quick pick widget.

On The resolved data interface for the promise of showQuickPick, I'm agree with you and I will update command to include the @file part.

cc @wsxiaoys

[zhanba]

Hi @zhanba, Thank you for the PR!

The current design is good, but I have some concerns.

Use the same or seperated quick pick widget

The current design use the same quick pick widget for input commands and selecting files, but

1. The quick pick widget auto-filters items by the current value. If we include both command list and file list in one quick pick list, all items need to be marked as alwaysShow to be visible, which may not be the ideal behavior of a quick pick widget.
2. The modal stack is not clear if we blend the quick pick widget. When the user triggers file selection, accepting (Enter or Click on item) will complete the file selection and continue the input command, but dismissing (Esc) will stop the input command instead of continue. By use a new quick pick widget for file selection, we can temporarily hide the command quick pick widget and show the file quick pick widget. Once it is hidden (by accept or dismiss), we update and show the command quick pick widget again to continue.

So, I suggest using a new quick pick for file selection with pushing modal stack.

How to trigger file selection

1. Using @:
   This keeps the UX consistent with the chat side panel. But, to achieve this in a quick pick widget, we need some tricky processing. Detecting whether the last character is @ to trigger should be good enough. However, there are some cons:

   • The @file is not highlighted to mark it includes a file context.
   • When the user moves the cursor and is not at the end and inputs something, the @ is not properly triggered.

2. Adding a button to trigger selecting files:
   This avoids a lot of tricky implementations but is not as convenient as using @.

3. Using a more customizable editor for inputting command:
   This should solve these problems in a cleaner way but requires a side view instead of using the quick pick widget.

I suggest keeping plan 1 for now.

The resolved data interface for the promise of showQuickPick

I think the @file should be kept in the command, as it can be part of a command. For example: A command could be Fix the use of function foo according to @foo.ts, where @foo.ts is included by selecting a file. Then the promise of showQuickPick should resolve as:

{
   "command": "Fix the use of function foo according to @foo.ts",
   "fileContexts": [{
      "referer": "@foo.ts",
      "uri": "file://path/to/foo.ts"
   }]
}

Let me know if you have any thoughts about these points. Also cc @wsxiaoys for design review.

I will try to use two quick pick widget and see how it works.

[zhanba]

two quick pick demo:
https://jam.dev/c/ce025a95-397d-47f4-8401-d9c41e56f6b8

[icycodes]

two quick pick demo: https://jam.dev/c/ce025a95-397d-47f4-8401-d9c41e56f6b8

Thank you for the quick update. This demo aligns with my thoughts, it looks much better to me.

[zhanba]

add smooth file deletion:
https://jam.dev/c/41e820ac-9f92-4736-b113-e21f8f9a7d39

[icycodes]

A map of label to file can't make this parseUserCommand just return string, because user may delete file mentions in command.

Before resolving the InlineEditComment, we can filter the context list by checking if the referer is still a substring included in the command.
This is just my idea. The current implementaion is also good and acceptable.

[icycodes]

Otherwise LGTM. Please rebase on main and resolve confilicts.

[zhanba]

Otherwise LGTM. Please rebase on main and resolve confilicts.

Rebased and Fixed

[icycodes]

The next task is to update the chat prompt template to include file context.
I think it can be done in a separate PR.
cc @wsxiaoys