search

Monokai / monokai-pro-sublime-text

Monokai Pro: beautiful functionality for professional developers
195 stars 7 forks source link

Dummy syntaxes break other packages #178

Open deathaxe opened 3 weeks ago

deathaxe commented 3 weeks ago

see: https://github.com/Thom1729/Sublime-JS-Custom/issues/146

There are other reports about normal syntax definitions not working, because dummy syntaxes of Monokai Pro theme overriding scopes.

Monokai commented 3 weeks ago

Hmm, I remember we had a conversation about this before. All I want is to give icons to certain file names instead of scopes. Currently, to my knowledge, the only way to achieve this is to generate dummy syntaxes. Any other ideas on how to achieve the same without getting in the way of other definitions?

deathaxe commented 3 weeks ago

Auto-generating syntax dummies if no corresponding real syntax definitions exist, is the only viable way.

Monokai commented 3 weeks ago

Would it help if I rename the scope source.graphql to stub.source.graphql for example?

deathaxe commented 3 weeks ago

Not really.

It would work around - include: scope:source.graphql using dummy syntaxes by accident.

It is however still likely a file is assigned the stub syntax stub.source.graphql when opened by user - depending on package and syntax names and loading order.

It would require users to manually re-assign file extensions to the real syntax, which I'd call bad UX.

Monokai commented 3 weeks ago

I agree it's bad UX. And I also think not having icons for certain file names is bad UX. So we're back where we've started:

  1. Either have filename-based icons and dummy syntax overrides.
  2. Or no syntax overrides, and also no filename-based icons.

I can understand why you're choosing option 2. But I'm getting lots of emails of users asking for filename-based icons. So I'm choosing option 1.

I really wish there was another way. Suggestions welcome.

deathaxe commented 3 weeks ago

Well, there are reasons for A File Icon doing what it does and being designed how it is.

If ST doesn't (and they most likely won't) provide proper infrastructure for "icon themes", a most suitable solution I could think of, was to use A File Icon as middleware which provides infrastructure to handle dummy syntaxes etc. and let themes just provide the icons.

It already prefers themes' icons if they announce icon support via .supports-a-file-icon-customization file.

The downside would be only basic icons being displayed without A File Icon being present, while full set of icons being available only with it.

IMHO, there should be only one package/plugin handling dummy syntaxes and file icon preferences in order to avoid conflicts.

I carry around the idea of a package which enables .sublime-icon-themes to enable users selecting their own icon sets like in VS Code.

Monokai commented 2 weeks ago

I understand your solution, but it's not optimal. There are two things that are holding me back:

  1. the user has to install an extra plugin
  2. file icons of A file icon (in different colors) appear in between Monokai Pro icons if Monokai Pro hasn't defined them.

It seems there's no solution without any downsides.