Of course, that’s usually a C header file and claimed by CLion or the C/C++ module, if installed.
In a V2 plugin, how can I assign only if not yet assigned?
<incompatible-with> does not work on module-level, so I can’t use it. It would have been ideally, because I could have added two modules. One with <incompatible-with> and the other one with <depends> on CLion.
<fileTypeDetector ...> is only invoked for unclaimed files, but plugins like TextMate usually claim the files (tested, TextMate was first).
<fileTypeOverrider> is similar. I don’t want to override a users’s choice and it’s expensive to call. Users would have no way to reassign back to CLion.
<languageSubstitutor> needs a language to substitute in the configuration. If CLion is not available, then there’s no base language to replace and the file type is not assigned to my plugin. Also, if it worked, I’d have to replace checks for fileType with checks for the PSI file’s language.
I’ll probably have to assign *.h to my own file type by default and let the user handle it.
I’m pretty sure that CLion users won’t like this, but I don’t see a better solution.
When users install a second plugin claiming FileType we show FileType conflict notification and suggest them decide what to keep.
Please note that we most likely will not promote any plugin for .h extension, as it is too widely used and distracting for users. As usual, promoting plugins to users in editor is matter of trust and our business directions
There is a fallback logic in the platform for them, TextMate file types claim them if there are no any plugins explicitly mapped
Thanks!
I’m aware of the conflict notification.
I’d like to know how to avoid it because I’m pretty sure that *.h should remain with CLion unless it’s an Objective-C project with *.h Objective-C files.
Only some projects will be Objective-C, but unfortunately file type associations are global. Depending on the project, a user would have to reassign back and forth between CLion C/C++ and my plugin. That’s bad.
I can only think of a FileTypeOverrider, which relies on a project setting. But that’s not a great solution.
Is there anything else in the SDK to improve this?
The problem boils down to:
if I assign with my <fileType... by default
CLion: not good. The conflict is displayed, but I don’t want that.
others: good
if I do NOT assign with my <fileType... by default
CLion: good
others: not good, because it’s claimed by TextMate and users won’t know that there is support
I’m totally fine with *.h not being advertised in the IDE. I’m more concerned with the in-IDE usability right now.
I ended up with a solution, where I only the main file extension to my plugin. *.h is not assigned by default, but an editor notification is displayed telling the user about the support and with an action to reassign. That’s hopefully the best usability.