API for using file quick open

[mjbvz]

Feature Request

Add api that lets extension show the file quick open UI to the user and get back the URI of the file that the user selected.

I imagine this API working like the existing showOpenDialog api, expect that will show a the quick open UI instead of the system file dialog (or the simple dialog)

Potential use cases:

• In Markdown, add a command that let users insert a link to an image that they select from quick open (#162809)
• In Jupyter notebooks, let users add image attachment to notebook using quick open
• In JS/TS and other languages, let users import a file that they select from quick open

This was previously requested in #37852, however making extensions implement this themselves will result in inconsistent UX and poor performance

I've tried using the workbench.action.quickOpen command but this command does not return the selected file

[TylerLeonhardt]

This provides the same functionality of the showOpenDialog but it doesn't honor the user's preference of the "file picking experience" that they've chosen since a user can decide to opt in to the simple file dialog.

Aren't we pretty firm that we don't do API that is just a UI difference?

cc @jrieken

[mjbvz]

@TylerLeonhardt I'd like quick open instead of the normal file browser. I don't think there's any way to show that today

With files.simpleDialog.enable, the UI I see for showOpenDialog looks like this

I'd instead like

[TylerLeonhardt]

I see... this makes sense to me. Though I also wonder if a mode in the Simple File Dialog makes sense for this case.

[DanTup]

I'd like this too. In Dart we have a command to "jump to test file for the current implementation file" (and vice versa).

In some cases, users keep tests in a folder that doesn't match the implementation so we can't easily find it. Being able to trigger the file quick-pick and pre-populate it with a query (based on the current open file basename, but with _test appended) would be really useful.

While they can just open the file picker themselves, it has no context that they might want the test file for the current open file, so they have to type enough characters to get the test file to the top (which in the cases reported to me, might involve a lot of characters).

[DanTup]

Probably as a workaround we can just executeCommand("workbench.action.quickOpen", term) and deal with the fallout if the args ever change 🙃

[eamodio]

I would really love this as well -- maybe a lightweight way would be to add a vscode.quickOpen (or vscode.quickFileOpen would be better) command that would be wait and return the Uri that was picked.

Right now the files.simpleDialog.enable experience of showOpenDialog is not remotely similar to the quick open experience (even when limited to files only), nor should it be imo -- showOpenDialog is more about the OS experience, so even in "simple" mode it should be more closely aligned with that behavior, while quick open is a rich fuzzy search (and quick open with multiselect would not work).

Additionally files.simpleDialog.enable with showOpenDialog is a user-level preference, not an extension choice either.

[eamodio]

@TylerLeonhardt this would be a pretty easy PR if you are open to it -- let me know.

[zWingz]

Is there any progress?