feat: Add alternative confirmation dialog using QuickPick (Enable with enableAlternateConfirmation)

[alilaa]

Title
Use QuickPick for change confirmation

Summary
Replaces modal confirmation with a QuickPick that lists pending file operations and applies on Enter, improving UX.

Changes

• Added confirmChanges.ts
  • Change type for create/delete/move/rename/copy/modify
  • confirmChanges() renders a read-only QuickPick with icons, relative paths, Apply/Cancel buttons, Enter=Apply, Esc/blur=Cancel
• Updated onDidSaveTextDocument.ts
  • Builds Change[], formats paths via formatPath, and gates execution on confirmChanges(...)
  • Keeps duplicate/overwrite conflict checks and all file ops logic intact
• Tests extension.test.ts
  • Stubs vscode.window.createQuickPick to auto-accept for deterministic runs
  • Retains showWarningMessage stub for legacy error dialogs
• Bumped package.json version to 0.0.31

Why

• Old dialog fail on long paths
• Clear, keyboard-first summary of actions

Behavior

• On save, a QuickPick shows the operations: create/delete/move/rename/copy/modify with VS Code icons and relative paths
• Enter or clicking “Apply” executes; Esc/clicking outside/“Cancel” aborts

Verification

• Covered by existing tests: create files/dirs (nested), rename/move, move+rename, directory moves, copy+move in one action, preview flows
• Manual: make edits in oil view, Save → QuickPick appears; Enter applies; Esc cancels

Files changed

• package.json
• onDidSaveTextDocument.ts
• extension.test.ts
• confirmChanges.ts (new)

[alilaa]

[corwinm]

Hi @alilaa! Thanks for opening this PR.

What was the issue mentioned where the dialog fails on longer paths? I haven't tested very long paths but if their is a known issue with just the dialog with longer paths, that would be good to note as an issue as well. Possibly this is a platform specific bug. I mainly use a Mac and occasionally a Ubuntu machine so a Window bug could easily get by me if its not caught by the tests. The dialogs are not able to be tested in the automated tests so that would have to be something that I occasionally test on different platforms.

I'm not sure I love the idea of using the quick pick for the confirmation. It could be a little confusing because usually a quick pick would be fore selecting a single action to perform. If you do select or filter the options and confirm the changes, all of the changes are still performed. It also looks like the quick pick doesn't prevent further actions/typing in the background and that could be a confusing experience.

I don't love the existing use of the dialog so something like the change here might be a good alternative option that could be opted into with a configuration flag. The existing dialog works with enter/esc for me. Ideally we would have a Y/N confirmation like the original oil.nvim plugin. I'm not sure if that is something that could be added to the dialogs or if the quick pick would support something like that.

Let me know your thoughts and I will play around with these changes on my local machine.

[alilaa]

Thank you for taking the time to review my PR. Sorry for being unclear, the main issue is related to long / deep paths, the path is truncated with no way to view the full path of the change.

This is fixed by the PR, its still truncated but can be hovered to show the full text.

I fully agree its a creative use of the dialog and might be confusing for first time users.

You also identified several issues with the dialog. I have updated the ui a bit but perhaps its still nog clean enough.
We now close on focus lost and only accept Y or N

[corwinm]

I played with it some more after the latest changes and their are a lot of things that I like about this. I am hesitant to make this the default but I can see some value in making this an experimental feature that can be opted into. If you want to make those changes let me know otherwise I can take that on.

I also looked at the original issue some more and the good/bad news is that it only impacts Windows OS. My testing on MacOS and Ubuntu showed that the text for long file paths wraps in the warning dialog. I am looking at a standalone fix for that problem that but that hopefully wouldn't really impact the changes here.

[alilaa]

Ah, that explains why it went unnoticed. Then an opt in feature seems like the way to go. I can update the PR, any preference for the name of the setting?

[corwinm]

Ah, that explains why it went unnoticed. Then an opt in feature seems like the way to go. I can update the PR, any preference for the name of the setting?

I think something like "enableAlternateConfirmation" or "enableExperimentalConfirmation" would work.

[alilaa]

I have updated the code accordingly, should we keep the quickpick mock, it wont be needed since testing is performed with setting off.

[corwinm]

I have updated the code accordingly, should we keep the quickpick mock, it wont be needed since testing is performed with setting off.

Yeah, good question. I think it's safe to remove the mock for now. Ideally I'll find a way to test the two flows but given it's a mock either way, we can stick to the single test path.

[corwinm]

This is looking really great. I'm excited to have this as an option!

[alilaa]

I have updated the code accordingly, should we keep the quickpick mock, it wont be needed since testing is performed with setting off.

Yeah, good question. I think it's safe to remove the mock for now. Ideally I'll find a way to test the two flows but given it's a mock either way, we can stick to the single test path.

Done. Let me know if there is anything else.