Separating theming and the language syntax for prose files

[maliayas]

Sublime Text has a good separation for language syntax and theming definitions.

However this separation is based on the assumption that the file is a code file. For this reason, the scopes that are expected to be defined by a color scheme are mostly limited to code scopes. Below are the scope list I took from Monokai theme:

comment
string
constant.numeric
constant.language
constant.character, constant.other
variable
keyword
storage
storage.type
entity.name.class
entity.other.inherited-class
entity.name.function
variable.parameter
entity.name.tag
entity.other.attribute-name
support.function
support.constant
support.type, support.class
support.other.variable
invalid
invalid.deprecated
meta.structure.dictionary.json string.quoted.double.json
meta.diff, meta.diff.header
markup.deleted
markup.inserted
markup.changed
constant.numeric.line-number
entity.name.filename
message.error

Apparently this doesn't work for prose files and such plugins (markdown etc) have to come up with their own color schemes. Thus there is no separation between snytax definiton and color scheme. Color scheme of one plugin can't be used with any other syntax file. Because everybody invents his own scope names.

Instead of this, language plugins for prose files should have common scope names to be defined. And there should be independant colors chemes that cover those scopes.

~~Regular color scehemes and prose file color schemes should not be combined.~~ I changed my mind. A regular color sheme might/should include support for prose scopes.

[sixty4k]

would it not perhaps be better to map the parts of prose documents to the standard (code) color scheme names so that any color scheme would be useful with both code and non-code texts?

[felixhao28]

@sixty4k This is certainly possible to achieve, but whether we should do it remains to be seen. I can think of several issues when using another programming-language-targeted color scheme:

1. People use mono-spaced fonts when programming. So few color schemes support bold, italics, _italicsbold_.
2. Markdown is designed to be compatible with html. Limited numbers of color schemes support html highlight.
3. Most importantly, is it a good practice to use "random" scope names just to have some colors on them? ST3 offers a shipped-in Markdown plugin which already introduces most of the names we use. We can of course invent a few that the vanilla doesn't cover. So I think maliayas may be exaggerating on this issue.
4. Finally, we can use different color schemes based on file types so why bother unifying it.

[maliayas]

4. Finally, we can use different color schemes based on file types so why bother unifying it.

Personally it is OK for me; but it is understandable for users to want to use their loved color scheme for markdown files. If we define a standart scope names list for our plugin (which consists of vanilla scopes + some custom ones we've invented) and publish it here, then it will become a virtual badge for being "markdown compatible" for thirdparty color schemes. I think many of them will join.

Also note that the proposal is not only for markdown but prose. So for example someone will be able to use our gray color scheme with AsciiDoc files etc. Standards for the good.

P.S.It's been 1 year since I've opened the issue and now I disagree with my last sentence there: "Regular color scehemes and prose file color schemes should not be combined.". I've edited it.

[maliayas]

Thanks for the ideas by the way.

[sixty4k]

Personally I want my color scheme to work across all file types. I think that the issue of a standard (super)set of scope names that color schemes should support is probably outside of this project's responsibilities, but I'm sure having a wiki page or README somewhere that documented the scopes necessary to be 'markdown compatible' would be great.

[felixhao28]

@sixty4k Here is what you are looking for:

CONTRIBUTING.md

[maliayas]

Maybe we should close this issue, because now I tend to think this is utopia. Our themes and scope names are tighly coupled. We can't expect AsciiDoc etc use the same definitions. If you agree, you can close this and undo 63377e6203796996613bee465e8a98235e0a2013. This repo's contributors doesn't need the list, because they can inspect the scopes by hand easily.

[felixhao28]

What are you talking about? This is a markdown plugin not a AsciiDoc plugin. And given the popularity of this plugin among markdown users, it is fair to give them a change to have more color options available don't you think so?

Our themes and scope names are tighly coupled

Of course they are tightly coupled. That's the way they are meant to work. At least we did't use any "text.blah.blah.markdownediting" type of scope names right?

This repo's contributors doesn't need the list, because they can inspect the scopes by hand easily.

Because they don't need to understand the syntax. They don't care about current color themes' details. They only want to know what the scopes are called.

[maliayas]

My fault if not clear but this issue was about building a bridge between ST and prose text plugins (markdown, asciidoc etc) So that all those plugins would use same scope names and color scheme implementors could support all at once.

This is what I know think utopia.

it is fair to give them a change to have more color options available don't you think so?

When somebody wants to create a new color scheme for our plugin, it's pretty straightforward. He will just fork one of the existing schemes and start playing. He doesn't need a list of scope names, especially when there is no description of those scopes.