This might actually sound stupid… and very likely not a Nova issue… but here it goes:
Once I’ve installed Nova for the first time (I migrated from Coda 2), eventually all languages I’m currently using and which define a filename extension (which, in my case, is all of them) will eventually get the attention of Finder, which, in turn, will visually change the files ending in that extension with Nova’s icon, to show that they can be opened with Nova.
This doesn’t happen with all files, of course. Filename extensions for JSON, JavaScript, XML, HTML, and so forth have previously been registered to be opened by other macOS applications — sometimes some that come with the operating system itself — and those will not be changed; you can manually tell macOS that you wish to open them with Nova, though; but the icon will not change.
In some cases, there are blatant inconsistencies. For instance, *.ts files, which is the preferred filename extension for TypeScript files, have ‘earned’ the Nova icon after installing @apexskier’s TypeScript extension; they are opened by Nova without issues, but Get Info thinks that they are MPEG-2 Transport Stream — which, unfortunately, also use the same filename extension as TypeScript. Because I have no other application installed that opens MPEG-2 transport streams, there is no problem — I can click on files with the .ts extension, they will be opened by Nova flawlessly and recognised as TypeScript, thus loading @apexskier’s complex extension, etc. All works as expected.
But what happens if you have a deeper conflict of filename extensions, such as having installed an application that can read/write/process such files, but these are in a completely different format?
Here is a simple example, before I give my own complex example, which shows the problem more clearly. Nova has support for reading and writing Markdown files (extension: .md), but for some serious editing, I normally use Typora. So the *.md files are ‘assigned’ to Typora and use Typora’s small icon, and Get Info shows that their type is Markdown document. Nova, of course, can read and write those as well, but the icon and type will not change; I can change the default application that opens *.md files to Nova — and that will certainly work as expected — but this will not affect the document type, not the icon.
This is because Typora registered Markdown files as their own first. According to the very complex Apple documents on this subject, which I do not comprehend fully, this is the expected behaviour: Typora got ‘first dibs’ with the original Uniform Type Identifier declaration for Markdown files, and macOS assigned those to Typora in perpetuity. Well, at least, while I still have Typora installed. Note that this is completely independent of what the Finder will use to open a *.md file — it can be set to any other application, but that doesn’t mean that this other application will become the new ‘owner’ of this filename extension. We’re talking about two levels here. One is at the filesystem level — identifying a file’s kind of document — and this is something dealt with by the Launch Services database. And the other is at the Finder level — a convenient, ubiquitous tool that lets you point-and-click a file and have it opened by the ‘correct’ application, something you define at the Finder level.
Keeping those two things in sync may not always be desirable, and, reversely, there are many occasions when you want to have a choice of several different applications when opening a specific document/file. In the example, I wish that Nova, Typora, Joplin, Agenda etc. are all ‘allowed’ to open Markdown files, but my primary Markdown editor is Typora (at least, for the purpose of this example!).
Ok, now let’s go to my scenario…
When I’m not tinkering with Nova’s extensions, most of my programming time is spent with Go, although PHP comes as a close second. I have nothing in my Mac that ‘understands’ *.go files, so, eventually, when I developed my Go extension for Nova, this was propagated to the Launch Services and to Finder. *.go files get the document type Go source and they get that cute icon that shows a tiny, tiny preview of the source code in it. Nova is set to be the default application opening those files. All’s well!
However, recent Go versions use more filename extensions for different purposes, namely, dealing with dependencies. This uses (at least) two files, go.mod and go.sum — the latter has no issues because no other application ‘understands’ *.sum files.
*.mod is another story.
Before I had installed Nova, I had installed VLC — a universal tool to play (and process) all sorts of media files. It does claim a lot of filename extensions, even quite exotic ones, because it needs to be able to be set as the ‘default’ application to open them. And here’s the catch: VLC thinks that *.mod files are MOD Audio Files, an obscure file format from 1987 that stored instruments and music-related information, which was used to make demos.
What happens now is that Nova also thinks that *.mod files are media files, not text files; therefore Nova launches an internal media player (I wasn’t even aware that this existed) and tries to open the file inside the media player… which naturally fails. I did not find a way for Nova to ‘ignore’ whatever macOS thinks about the file type and just read it ‘raw’. It’s something I simply cannot edit in Nova!
As it turns out, picking the *.mod extension is a really, really bad idea. Back in 2015, someone had a real nightmare struggling with having two applications (one of which was VLC) fighting over the claim of that filename extension and set its type. The hacking approach, manually introducing the correct information for that kind of file into an app’s pinfo.list, might have worked in 2015, but since then you simply cannot change anything inside an app without breaking its signature — and macOS will refuse to launch such an app.
An apparent workaround is to create a new application and try to wrestle away the .mod extension, claim it as its own, and change the file type. This seems to be a drastic way of fixing what amounts to a ‘simple’ (internal) database change! It should not be that complicated…
I haven’t tried the latter suggestion (yet!), because first I need to understand how Nova handles things on its own side.
I thought that what Nova did was to capture whatever filename extensions are defined as an extension’s filename on its extension.json file; in other words, I believed that this would be the simplest approach — creating a new Nova extension that claims .mod files as their own, and propagate that knowledge automatically to the Mac’s Launch Services database. I guess I was just being naïve 
I’ve also added the *.mod extension on all places I could find, such as on the project definitions, even on the FTP settings for ASCII-only files, etc. No luck: Nova still persists in believing that it’s a media file, and refuses to open it outside the built-in media player.
My last option, of course, is to remove VLC — and with that the claim that VLC has over the .mod extension — and eventually do a Launch Services database reset, do a few reboots, reinstall Nova, etc. until the Launch Services database correctly assigns that extension to Nova (I only wonder if when re-installing VLC again it will ‘steal’ the extension from Nova — I did remove .mod from the list of extensions that VLC is supposed to register as their own, but that didn’t make any difference, and when reinstalling VLC, I can assume that most of those configuration details will be lost, and VLC will revert to its default, that is, claiming .mod files). I did not make this experiment — yet — because, well, I need VLC for a few things, and I most certainly don’t want to have it permanently removed just because Nova is unable to open only one type of files!
All right, this is naturally just an example, to give you a taste of what can go wrong with filename extensions; my particular case is not hypothetical, but real, and because so many applications share potential extensions, this will be an ongoing problem. Note that this is not Nova’s ‘fault’, it’s just the way macOS has been designed; it’s also not really VLC’s fault (they do support MOD Audio Files, at a time when there are few applications around which can open these).
TL;DR…
- When Nova loads a new extension, which defines a filename extension, will that extension be registered with the Launch Services database automatically, so that it’s assigned to Nova?
- If not, is there a system-wide mechanism to let macOS know which extension is assigned to Nova (and Nova only), i.e. going beyond merely selecting the default application that opens that kind of file?
- Is there any way to manipulate the Launch Services database directly, as opposed to working loops around it, namely, developing a small app just for the purpose of ‘grabbing’ a certain filename extension that has gone ‘rogue’ (i.e. assigned to the wrong application and having the wrong type)? I’m assuming a command-line interface to the Launch Services database (if such a thing exists, since I haven’t been able to find it… all we’ve got is
lsregister, which can do little more than a full database reset…), but a GUI app would suit me just fine.
I guess that’s it 