Plain text files are not correctly detected.

[0xjac]

Describe the bug

I opened my sway configuration file. It's a plain text file (detected as such by JetBrains) with a .conf extension. (Similar to this) and no color highlighting takes place.

If I add a .md extension, then it works fine (besides the broken MD syntax). If I add a .txt it also does not work.

I have enabled the settings to parse text files.

To Reproduce

1. Install Color Highlighter in your JetBrains IDE.
2. Go to Settings → Editor → Color Highlighter, expand Text Settings, and tick Parse Colors in Text Files.
3. Download a sample file:

   wget https://raw.githubusercontent.com/manjaro-sway/desktop-settings/sway/community/sway/usr/share/sway/themes/matcha-blue/theme.conf

4. Open said file (theme.conf) with your JetBrains IDE.

Expected Behavior

When opening a file associated to the plaintext type, colors should be highlighted regardless of the file extension.

I believe the issue comes from the TextVisitor, here. I'm not familiar with Kotlin and I don't know why it doesn't work with a .txt extension.

Maybe the visitor should check for both a (configurable ?) set of extensions or whether the PsiFile is an instance of PsiPlainTextFile, similar to what the JavaVisitor does.

Environment

GoLand 2024.1.2
Build #GO-241.17011.92, built on May 23, 2024
Runtime version: 21.0.2+13-b375.1 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.6.30-2-manjaro
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 3964M
Cores: 12
Registry:
  ide.completion.variant.limit=500
  suggest.all.run.configurations.from.context=true
  ide.experimental.ui=true
Non-Bundled Plugins:
  org.toml.lang (241.17011.8)
  com.github.lonre.gruvbox-intellij-theme (0.6.2)
  com.mallowigi.colorHighlighter (18.0.0)
Current Desktop: sway

Screenshots

[mallowigi]

Not sure why it doesn't work, it seems to work just fine in my sandbox.

I've added the conf to the list of extensions handled by TextVisitor, it seems to work (but you'll lose all the other highlightings for conf files provided by other plugins)

I guess adding a configurable list of extensions shouldn't be too hard. Also a better way would be to expose an extension point so that other plugins can plug themselves to this plugin and efine their own visitors, but I am skeptical on how many would actually try to do this.

I'll add this to my backlog anyway, can't hurt to try somehting new.