Define editor per backend or rely on system default for filetype

[mxa]

With the current implementation Rack will accept one editor for all backends. However it doesn't make much sense to open .pd files with a code editor.
Suggestion: Remove the option to set an editor in Rack altogether and rather rely on the system to open the file with the associated program to the file-type, a.k.a. xdg-open on Linux.

[AndrewBelt]

I suspected you'd say this, so good job, you're doing things as expected. :)

What I'll do is make the libpd ScriptEngine have a "special" editor defined by a "puredataPath" property in the global settings.

[mxa]

OK.
For the record, .pd files should always be associated with the pd-gui binary (not with the pd binary, that will open another instance of Pd on every call).

[mxa]

Let me park a "note-to-self" here because it is relevant in this context:
Opening a code snippet from Rack in an editor is exposing normal behaviour: Editing in the code is not affecting the sound output and it will only reload (or JIT-compiled) once it is saved. However: Opening a Pd patch from Rack in a separate instance of Pd will be a bit confusing, because it goes against the expectations of a realtime programming language such as Pd. Changing the patch contents is not affecting the output immediately, as Pd-users would expect.
This is probably the reason why libpd has an experimental feature which is to open a GUI which will directly attach to the running patch and affect it in realtime. However it is crashy: pressing Control-D for example will take the whole libpd instance down. If this feature ever works properly, this might be nice to migrate to this over launching a parallel instance of Pd to open the patch.