Provide custom editor widget for given file extension via plugin

[zuckerruebe]

Issue Report Checklist

N/A

Problem Description

Is it possible to associate a file extension with a plugin's widget such that when a user requests opening a file the plugin's widget is used to open/edit the file and not the built in editor plugin?

What steps reproduce the problem?

N/A

What is the expected output? What do you see instead?

N/A

Paste Traceback/Error Below (if applicable)

N/A

Versions

Newest release version

Dependencies

N/A

[ccordoba12]

Hey @zuckerruebe, thanks for reporting. You said:

Is it possible to associate a file extension with a plugin's widget such that when a user requests opening a file the plugin's widget is used to open/edit the file and not the built in editor plugin?

This is not possible at the moment but we'll work on it for Spyder 6.1, to be released at the beginning of next year.

It's important for us to solve it because that way users will be able to open Jupyter notebooks directly in our Spyder-notebook plugin. If it's ok for you, could you share why you need this functionality?

[zuckerruebe]

Hi @ccordoba12 ! Sure, thanks for your reply. I'm one of the developers of pytrnsys. It's a PyQt based GUI to draw hydraulic schemes like this one:

From the graphical hydraulic scheme you'd then export a textual description of the system in a so-called "deck" file which then serves as the input to TRNSYS, the program that we used to then actually simulate the system.

But before your simulation is ready to be run, you'd first have to implement a few things - chiefly the control strategy of the system - within TRNSYS's textual input language mentioned above.

To do that, you need a text editor, of course - ideally one with an idea of the structure of a deck file for syntax highlighting, navigation, etc. (LSP!). Currently, we're using, e.g., Visual Studio Code for that. But that means having to switch back and forth between programs, telling users to also install Code, etc.

Hence the idea to be able to edit both the ddck file and the graphical diagram within Spyder.

I'm glad to hear that this is something you're thinking about for the next release. Is there something on the development branch with regards to this that I can program against/try out or is it too early days?

Cheers!

[zuckerruebe]

I'm glad to hear that this is something you're thinking about for the next release. Is there something on the development branch with regards to this that I can program against/try out or is it too early days?

@ccordoba12 We'll soon have to take a decision on whether we have to fork or can go with only a plugin, so a quick feedback would be much appreciated.

[jitseniesen]

I am developing the Spyder notebook plugin. I plan in the next weeks to take the existing but outdated PR #8798 and update it for the latest release of Spyder so that notebook files can be opened in the notebook plugin. This mechanism should also work for ddck files, as I understand it.

[zuckerruebe]

Hi @jitseniesen

Thanks for your reply. Would that PR also address opening a file by clicking on it in the explorer/file system tree plugin? If I undestand correctly, you'd "backport" it to the latest release of Spyder? Or merge it into main?

[jitseniesen]

@zuckerruebe Yes, you can also open the file in your plugin by clicking on it in the File or Project explorer, at least that is my intention. Thanks for mentioning it, I will check in due time that this actually works.

My expectation is that this will be included in Spyder 6.1.0 but that is not up to me.

[ccordoba12]

To complement what @jitseniesen said, our 6.1.0 version will be available in six months or so.

[zuckerruebe]

Thanks, everyone!

[jitseniesen]

Hi @zuckerruebe. I am going through all the file-related items in Spyder's file menu: New file, Open, Open last closed, Open recent, Save, Save all, Save as, Save copy as, Revert, Close, Close all. Our current thinking is that a plugin will probably be either be interested in all of them or none of them. So my question is: would you want to implement all of these in your plugin? Or would some of these not make sense for your use case?