Cannot open a file using a preferred factory from launcher

[jschaeck]

Problem

Using the great extensibility of Jupyterlab, I was able to create my own editor for .py files. As I have an according widget registry, it is automatically used when double clicking a .py file or using the "Open from Path..." command

On the launcher, there is already a default python file entry. From a use case perspective, there is no need for me to replace that. What I need is that after creating a new .py file via launcher (or the alternative ways via Menu, Command Palette) my own editor is used (my widget factory is used) as the default

It seems the implementation of fileeditor:create-new is preventing this as it hard codes the factory to editor

const widget = (await commands.execute('docmanager:open', {
path: model.path,
factory: FACTORY
}))

Proposed Solution

Instead of hard coding editor, ask the document registry for the preferred widget factory for the path and use what is returned there (assuming this is possible but as in all other places my factory is used automatically, it seems to exist)

[jschaeck]

Maybe a solution could also be to not pass the factory at all (which open path seems to do) as then in the document manager at some place this is called: const factory = this.registry.defaultWidgetFactory(newPath);

[krassowski]

Let's take a step back. Why does the launcher depend on fileeditor and use fileeditor:create-new? This is the functionality:

jupyterlab/packages/fileeditor-extension/src/commands.ts

Lines 1066 to 1084 in 846a7b0

	async function createNew(
	commands: CommandRegistry,
	cwd: string,
	ext: string = 'txt'
	) {
	const model = await commands.execute('docmanager:new-untitled', {
	path: cwd,
	type: 'file',
	ext
	});
	if (model != undefined) {
	const widget = (await commands.execute('docmanager:open', {
	path: model.path,
	factory: FACTORY
	})) as unknown as IDocumentWidget;
	widget.isUntitled = true;
	return widget;
	}
	}

It feels justified that fileeditor has a hard-coded factory - it is what the command does (creates and opens in file editor). Launcher could possibly duplicate it but without the hardcoded factory, or maybe there should be a command in docmanager for "create-and-open"? But then, when opening from laucher we do want to ensure we open the editable representation. Think about a HTML file. If someone added a HTML tile in the launcher they would want to create an empty untitled.html and then open it in an editor rather than view rendering of an empty page, right?

So I think maybe we need to augment the factories to distinguish between "viewers" and "editors" and then docmanager could have "create-and-open" called from the launcher with factory: "prefer-editor" (or a boolean or something). Or maybe to avoid command creep we would just add this argument to docmanager:open and duplicate the above two-liner directly in launcher.

How does it sound?

[jschaeck]

Thanks for your reply.

If I understand correctly, you are saying that it is fine for file editor to hard code the extension in its own command , which I can understand. In that case, could file editor maybe changed to be configurable so that consumers can influence what it registers and what not to avoid overlap with custom functionality?

So instead of the approach to reuse an existing launcher icon with a custom factory, have a custom icon but be able to hide the default one?