Oh, open vs openExternal not nice but understood. I think it should still use the opener-logic tho

@jrieken to be clear: instead of having a separate service, we allow to register an opener that takes care of the openExternal thingy for electron only from VSCode desktop?

Yeah, well actually two issues

• Generally, I think one opener service is better than two, esp since the former allows contributions.
• Tho I think it's weird that IOpenerService has open and openExternal esp. since the implementation of open calls openExternal. As a consumer, how would I know what to call? Should consumers look at schemes first? Should openExternal maybe be internal and be used as fallback in case we cannot open something with the registered openers?

@jrieken yeah I can see to get the count to 2.

We can think about merging open and openExternal but for now I would prefer to preserve our existing behaviour as much as possible. After all, open is doing things different from openExternal (e.g. sometimes it runs a command or opens a file), so we cannot just merge them both into one unless we would introduce an option (which is similar to having 2 methods).