[core] (Windows) Implement Specific File Handler Functionality

[confused-Techie]

This PR relates to #803

This PR implements the logic needed for that PR to actually work. At least the baseline logic needed on Windows Systems.

This PR would ensure that for supported file types we are able to set specific icons for those files. If we create a generic icon that could also be used for a more extensive list of "supported" file types, which would likely see the most benefit from being used to cover all file types supported by the default grammars installed within Pulsar.

But again it's good to keep in mind this does not address this behavior at all on Linux or macOS. And as of currently is missing the implementation of this behavior into functionality within the settings-view package.

[confused-Techie]

So I've just begun my work back up on here, and have some notes I'd like to add.

While there have been some pretty great success, allowing a settings menu like the one below to create these results:

Don't mind .js being incorrect, I'll get to that in a moment.

While this looks great, and seems like a great start, I'd like to mark down some of the issues I'm encountering, that don't have perfect solutions just yet.

• Changing Previous Settings: Like we can see with the .js file, there's some unknown value that's causing it's previous associations to not be forgotten or overridden. In the past I had set Windows to always open .js files using Pulsar. Windows default behavior in this case would be to use the .ico image of the executable program as the icon for the file type as well. But when working on this I had wanted to unset this previous behavior. But it turns out there seems to be no supported method to unset a previous file association on Windows. And unfortunately setting Pulsar in the way I do in this PR, didn't override this previous association. So I ended up manually removing the association via Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.js\OpenWithProgids where I deleted the entire subkey of OpenWithProgids, which did successfully remove Pulsar as the default opener, bringing the value back to the Windows default, but unfortunately still, I couldn't then get that to be automatically changed via this PR later. So if we want this to take precedence over other applications once set, we need to find some way to do this correctly and automatically.
• Opening: So to quickly get into how we are attempting to open these applications:
  • We add a ProgID key to the file extension we want to open: Computer\HKEY_CURRENT_USER\SOFTWARE\Classes\.cs\OpenWithProgids with the added Key "Pulsar.cs". This essentially tells Windows to open *.cs files with the ProgID Pulsar.cs
  • We then create the Pulsar.cs ProgID. In this we add some other data, like the AppUserModelID which can let Windows correlate it with the actual Pulsar executable, document history, etc. The command to actually open the file within Pulsar, and of course the DefaultIcon being the icon used to represent this file on the system. The fact that we want a different icon shown per application type is why we must create a new ProgID per file type.

So with the how out of the way, lets try to dive into some of the issues with this.
With what I've said above, I had assumed things would work, we add our ProdID to the file extension, then setup the ProgID to open the Pulsar executable. Except, when I then double click any of the files to open them, I get the following menu:

In this image you can see the issue at hand. That first entry of Pulsar with the white background, isn't actually Pulsar. As far as I can gather, that's the ProdID itself, which if I click to open with that first application, the same menu appears again, and again, never actually opening the file.

If I want to open it, I have to select the second Pulsar entry, which is the actual Pulsar executable, which we know because it's showing an accurate .ico application icon. Clicking this opens the file, and leaves the file extensions icon as the new one we set. But obviously users shouldn't have to deal with this small headache, or have to manually find the "right" instance of Pulsar.

So obviously something very funky is going on here, and in my current research I'm unable to uncover exactly what that is.

But onto the last other issues here.

• The current ShellOption within win-shell.js and possibly even winreg as a dependency makes it a bit difficult to work with the registry the way we need to. Now this could just be funkiness in my code, or synchronous issues, but we can't seem to ever correctly check if any one of these options is set. That's because unlike all previous entries in this file, this new behavior doesn't have a novel top level key. Previous entries like to setup right click context menus, or folder menus, all are added a key that is the name of the application executable, meaning that if we want to check if the setting is set, we can just check for it's existence. But in our new changes, we are adding our initial values to a file extension key, which always exists. Meaning we can't actually tell if we set things properly by it's presence. But this is something that should be solvable, but still has given me more issue than I'd like it too, so I'm adding it as an update.

---

That's all to say, I'm still working on this one, and due to this issues may take some extra time to sort out these strange behaviors.

[confused-Techie]

So another quick update.

As you can see on my last commit I was able to work out exactly what was going wrong with opening the application. This now means that amazingly when the icon is double clicked it opens within Pulsar right away, without issue.

Additionally, after doing some research, I may look at the feasibility of migrating all registry handling to registry-js. Like I mentioned the way this file exists currently makes the way we need to check for keys difficult, and that comes at the cost of the interface of the dependency win-reg. But I found registry-js which in it's docs says that it has all the functions that "Atom" needs. Since it was also made by GitHub, it makes me think they had at some point intended to migrate over, so might be nice to do that ourselves now.