Add more languages

[Anviking]

No description provided.

[ndrewh]

Not my project, but it appears that this would require making more .json files for languages. Heres the one thats included:

{
    "import" : "c", // imports c.json
    "language" : "objective-c", //
    "filetypes" : ["m" "h"],
    "patterns" : [
                  {
                  "name" : "blockComments",
                  "color" : "JLTokenTypeComment",
                  "regex" : "/\\*([^*]|[\\r\\n]|(\\*+([^*/]|[\\r\\n])))*\\*+/",
                  },
                  {
                  "name" : "lineComments",
                  "color" : "JLTokenTypeComment",
                  "regex" : "//.*+\n",
                  },
                  {
                  "name" : "block comments",
                  "color" : "JLTokenTypeComment",
                  "regex" : "/\\*([^*]|[\\r\\n]|(\\*+([^*/]|[\\r\\n])))*\\*+/",
                  },
                  {
                  "name" : "block comments",
                  "color" : "JLTokenTypeComment",
                  "regex" : "/\\*([^*]|[\\r\\n]|(\\*+([^*/]|[\\r\\n])))*\\*+/",
                  },
                  ],

}

[zyavrik]

Objective-C syntax and integrated themes should be moved to external (maybe .json) files.

[ndrewh]

@altaveron I think it allready is https://github.com/Anviking/Chromatism/blob/master/Chromatism/Chromatism/test.json

Or at least was attempted.

[Anviking]

It was attempted. I'm yet not happy with how the syntax highlighting is done, and I want to be more sure about it before possibly moving regex-patterns and themes to external files.

[ac3xx]

I've started a possible externalisation on my fork of the project (ac3xx/Chromatism@bcd71e9) - split out the Objective-C regex into an external plist and started a CSS one (although the regex for that still has a few bugs). Any thoughts would be good.

[Anviking]

@ac3xx Looks amazing, will take a closer look later. However, the plists need to be in a bundle, right?

[ac3xx]

@Anviking Yes, they will need to be, static libraries can't contain resources. The CSS highlighter has some bugs associated (bad regex mainly), but the basis is there :). To test as it is, just link the plists that are in the Lexers folder to the project you're testing with (Supporting Files).

[Anviking]

@ac3xx Your additions are most welcome! I'm not still convinced, but if you'd move the dynamic-plist-parsing to a cleverly named initialization-method I'm very happy to merge a PR. If you want you could call your custom initialization method from -init, but make sure to add the resources to a bundle then.

Basically I don't like plists because I think they are so annoying to edit. I was thinking about a JLTokenizer subclass for each language or having dictionary-like representations (much like the plists but in objc-code the overall convenience) in one or multiple files.

[ac3xx]

@Anviking Okay, sure, I'll take a look into cleaning it up with initialisation methods/bundles/etc later this week when I get some free time.

To a certain extent I agree with you (it took me a while to create that plist for Objective-C). My only argument for having plists over subclasses/dictionary representations is that it's overall regarded as more intuitive and "safe" for expandability - devs can just drop in any extra plist files they might want to use and instantly use them with a method call.

[ndrewh]

Plists really aren't all that bad to edit in Xcode. I'd personally prefer them over subclasses (they are "drop in") However, subclasses could allow more flexibility (direct method customization rather than strings in a plist). I think this a decision that should be considered further.

Sent from my iPhone

On Nov 12, 2013, at 2:06 PM, James Long [email protected] wrote:

@Anviking Okay, sure, I'll take a look into cleaning it up with initialisation methods/bundles/etc later this week when I get some free time.

To a certain extent I agree with you (it took me a while to create that plist for Objective-C). My only argument for having plists over subclasses/dictionary representations is that it's overall regarded as more intuitive and "safe" for expandability - devs can just drop in any extra plist files they might want to use and instantly use them with a method call.

—
Reply to this email directly or view it on GitHub.

[Anviking]

Then, wouldn't subclassing JLTokenizer inside the library be perfect then as long as we support initialization from plists at the same time for other developers? I am worried about the inflexibility of plists, if Chromatism would develop any more complicated features.

[ndrewh]

@Anviking Yeah, both would be good. :)

[mbcoder17]

How would I be able to add Java support to this library?

[Anviking]

@mbcoder17 There is no guide/documentation, but you look at how its done for C, ObjC and Swift.