[GH-ISSUE #54] Syntax highlighting on upgrade to Atom 0.200

gitea-mirror commented

2026-05-05 14:59:44 -06:00

Owner

Originally created by @damonmcminn on GitHub (May 22, 2015).
Original GitHub issue: https://github.com/awatson1978/meteor-api/issues/54

Atom 0.200 default auto-detected grammar is determined by installed packages i.e. if meteor-api is installed, the default .js grammar is JavaScript (Meteor).

The syntax highlighting does not work as expected, see below.

With JavaScript (Meteor):

With default JavaScript grammar:

Originally created by @damonmcminn on GitHub (May 22, 2015). Original GitHub issue: https://github.com/awatson1978/meteor-api/issues/54 Atom 0.200 default auto-detected grammar is determined by installed packages i.e. if `meteor-api` is installed, the default `.js` grammar is `JavaScript (Meteor)`. The syntax highlighting does not work as expected, see below. With `JavaScript (Meteor)`: ![selection_001](https://cloud.githubusercontent.com/assets/5415900/7767043/2d88322e-0067-11e5-9f16-64c1863c451a.png) With default JavaScript grammar: ![selection_002](https://cloud.githubusercontent.com/assets/5415900/7767044/2d89e2f4-0067-11e5-8308-9f831301b4c8.png)

gitea-mirror closed this issue

2026-05-05 14:59:47 -06:00

gitea-mirror commented

2026-05-05 14:59:49 -06:00

Author

Owner

@kfalkiewicz commented on GitHub (May 23, 2015):

I saw this today, working with Angular. Something isn't correct here. Please fix this asap.

@kfalkiewicz commented on GitHub (May 23, 2015): I saw this today, working with Angular. Something isn't correct here. Please fix this asap.

gitea-mirror commented

2026-05-05 14:59:53 -06:00

Author

Owner

@awatson1978 commented on GitHub (May 26, 2015):

The code for this stuff is all regexs and coffeescript and atom's own package manager. So, while it's ostensibly Javascript/Meteor, it's a pain to rig everything up. This is on my list of things to do the next time I'm doing an upgrade to Atom though, which should be in the next couple of weeks hopefully. If anybody wants to help with regexes, I'd consider a pull-request on this.

@awatson1978 commented on GitHub (May 26, 2015): The code for this stuff is all regexs and coffeescript and atom's own package manager. So, while it's ostensibly Javascript/Meteor, it's a pain to rig everything up. This is on my list of things to do the next time I'm doing an upgrade to Atom though, which should be in the next couple of weeks hopefully. If anybody wants to help with regexes, I'd consider a pull-request on this.

gitea-mirror commented

2026-05-05 14:59:55 -06:00

Author

Owner

@damonmcminn commented on GitHub (May 26, 2015):

I'm happy to take a look at this, just need a little direction in where to start looking and how to test?

@damonmcminn commented on GitHub (May 26, 2015): I'm happy to take a look at this, just need a little direction in where to start looking and how to test?

gitea-mirror commented

2026-05-05 14:59:57 -06:00

Author

Owner

@awatson1978 commented on GitHub (May 26, 2015):

Cool. Take a look at your ~/.atom/packages directory. You should find ~/.atom/packages/meteor-api. Move that somewhere, and clone this repo where it used to be. (You'll want to fork it first to your own account.)

# download the meteor-api package to the correct location
cd ~/.atom/packages
mv meteor-api meteor-api-bkup
git clone http://github.com/damonmcminn/meteor-api
cd meteor-api

# make sure you're on a feature branch 
git branch
git checkout -b syntax-highlighting

# open a new atom editor in the current directory
# we're using atom to hack on an atom package; spiffy recursive recursive!
atom .

You'll then want to go into the meteor-api/grammars/ directory and start hacking on meteor-api-grammar-javascript.cson and the other files there.

The hotkey command to reload the packages into Atom is Control+Option+Command+L.

Once you hack on things a bit, submit a pull request (to develop would be best; but I wont nitpick), and I'll go through the publication process.

Thank you for the help!

@awatson1978 commented on GitHub (May 26, 2015): Cool. Take a look at your `~/.atom/packages` directory. You should find `~/.atom/packages/meteor-api`. Move that somewhere, and clone this repo where it used to be. (You'll want to fork it first to your own account.) ``` sh # download the meteor-api package to the correct location cd ~/.atom/packages mv meteor-api meteor-api-bkup git clone http://github.com/damonmcminn/meteor-api cd meteor-api # make sure you're on a feature branch git branch git checkout -b syntax-highlighting # open a new atom editor in the current directory # we're using atom to hack on an atom package; spiffy recursive recursive! atom . ``` You'll then want to go into the `meteor-api/grammars/` directory and start hacking on `meteor-api-grammar-javascript.cson` and the other files there. The hotkey command to reload the packages into Atom is `Control+Option+Command+L`. Once you hack on things a bit, submit a pull request (to develop would be best; but I wont nitpick), and I'll go through the publication process. Thank you for the help!

gitea-mirror commented

2026-05-05 14:59:58 -06:00

Author

Owner

@maciej-trebacz commented on GitHub (Jun 25, 2015):

Is this fixed yet? It doesn't look right for me:

@maciej-trebacz commented on GitHub (Jun 25, 2015): Is this fixed yet? It doesn't look right for me: ![zrzut ekranu 2015-06-25 18 26 32](https://cloud.githubusercontent.com/assets/1614514/8359609/c1b1e290-1b67-11e5-8870-b14372baf4d2.png)

gitea-mirror commented

2026-05-05 14:59:59 -06:00

Author

Owner

@damonmcminn commented on GitHub (Jun 29, 2015):

@awatson1978 What is the reasoning behind commenting out a number of the patterns? As Atom defaults to package grammars, my approach would be to wholesale copy the shipped JavaScript grammar and extend it by matching specific Meteor patterns.

@damonmcminn commented on GitHub (Jun 29, 2015): @awatson1978 What is the reasoning behind commenting out a number of the patterns? As Atom defaults to package grammars, my approach would be to wholesale copy the shipped JavaScript grammar and extend it by matching specific Meteor patterns.

gitea-mirror commented

2026-05-05 15:00:01 -06:00

Author

Owner

@awatson1978 commented on GitHub (Jun 29, 2015):

No specific architectural reason. It's just an artifact of getting an initial demo to work. There were two problems I ran into when I was getting the initial version working: first, some of the rules overlap. When they do, last one loaded wins. So just adding rules to the existing ones can be a bit frustrating to debug. Second, there's only about two dozen colors that can be displayed at the same time before the eye starts confusing shades. If green is used for text strings, you might be able to get away with adding a dark green and light green for other rules; but you can't just add a different shade of green for each rule. It will be unreadable. Plus the color background cuts your color space in half. End result is that it's difficult to display more than a dozen unique rules in a color space.

@awatson1978 commented on GitHub (Jun 29, 2015): No specific architectural reason. It's just an artifact of getting an initial demo to work. There were two problems I ran into when I was getting the initial version working: first, some of the rules overlap. When they do, last one loaded wins. So just adding rules to the existing ones can be a bit frustrating to debug. Second, there's only about two dozen colors that can be displayed at the same time before the eye starts confusing shades. If green is used for text strings, you might be able to get away with adding a dark green and light green for other rules; but you can't just add a different shade of green for each rule. It will be unreadable. Plus the color background cuts your color space in half. End result is that it's difficult to display more than a dozen unique rules in a color space.

gitea-mirror commented

2026-05-05 15:00:02 -06:00

Author

Owner

@maciej-trebacz commented on GitHub (Jun 29, 2015):

You can reuse colors, but the point is that right now most of the code has "default gray" color, which makes the Meteor syntax highlighting much less useful from the original Javascript one.

@maciej-trebacz commented on GitHub (Jun 29, 2015): You can reuse colors, but the point is that right now most of the code has "default gray" color, which makes the Meteor syntax highlighting much less useful from the original Javascript one.

gitea-mirror commented

2026-05-05 15:00:04 -06:00

Author

Owner

@awatson1978 commented on GitHub (Jun 29, 2015):

Like I said... I'm willing to take pull requests on this. I did all the research on how to do this. And I put something together that was useful for me. If people have ideas on how to improve things, I'm willing to merge ideas in.

@awatson1978 commented on GitHub (Jun 29, 2015): Like I said... I'm willing to take pull requests on this. I did all the research on how to do this. And I put something together that was useful for me. If people have ideas on how to improve things, I'm willing to merge ideas in.

gitea-mirror commented

2026-05-05 15:00:06 -06:00

Author

Owner

@damonmcminn commented on GitHub (Jul 1, 2015):

@awatson1978 with #55 I uncommented only a couple of sections. It didn't work entirely to my satisfaction and I stepped away from Meteor for a bit so only picking this up again now.

My intention is to take the base JavaScript grammar and add as much Meteor sauce as I can without breaking the base grammar i.e. as Atom defaults to using the JavaScript (Meteor) grammar, my opinion is said grammar must still work as expected for all JavaScript files, regardless whether they exist in a Meteor context or not.

Is this acceptable to you?

@damonmcminn commented on GitHub (Jul 1, 2015): @awatson1978 with #55 I uncommented only a couple of sections. It didn't work entirely to my satisfaction and I stepped away from Meteor for a bit so only picking this up again now. My intention is to take the base JavaScript grammar and add as much Meteor sauce as I can without breaking the base grammar i.e. as Atom defaults to using the JavaScript (Meteor) grammar, my opinion is said grammar must still work as expected for all JavaScript files, regardless whether they exist in a Meteor context or not. Is this acceptable to you?

gitea-mirror commented

2026-05-05 15:00:08 -06:00

Author

Owner

@awatson1978 commented on GitHub (Jul 1, 2015):

Hi, just published version 2.20.0. Should contain:

color syntax highlighting for language constants
color syntax highlighting for meta functions
template snippet updates
route snippet updates

@awatson1978 commented on GitHub (Jul 1, 2015): Hi, just published version `2.20.0`. Should contain: - color syntax highlighting for language constants - color syntax highlighting for meta functions - template snippet updates - route snippet updates

gitea-mirror commented

2026-05-05 15:00:10 -06:00

Author

Owner

@damonmcminn commented on GitHub (Jul 5, 2015):

Superb! Love your work :)

@damonmcminn commented on GitHub (Jul 5, 2015): Superb! Love your work :)

gitea-mirror commented

2026-05-05 15:00:12 -06:00

Author

Owner

@awatson1978 commented on GitHub (Jul 6, 2015):

Thanks! Glad you see the value! The Meteor API package is one of the hidden gems, and since you're clued in on this package, you're probably one of the few that will appreciate the details of the roadmap.

Take a close look at the 'extract-method' package. It's ostensibly written for Ruby, but it has the complete pattern for adding menu items to Atom. The next big milestone of the 'meteor-api' package is to pretty much incorporate the entire 'extract-method' package, and adjust the three or four lines of ruby code into node/javascript.
https://atom.io/packages/extract-method

Then. Take a look at starrynight.meteor.com. It's the node utility I've been working on. A bit of a hodge-podge, everything-and-the-kitchen-sink sort of utility.
https://github.com/awatson1978/starrynight

You'll see a few interesting commands, such as:

starrynight rename --from /path/to/component --to /new/path
starrynight find-and-replace --from oldTerm --to newTerm

These are intended to be hooked up to the Atom UI. So, StarryNight and Meteor-API are going to converge.

Also. With the StarryNight utility, we've managed to swap out the Firfox browser of Nightwatch with Chrome; and the Phantom browser of TinyTest with Chrome. Add in Meteor-Api, which provides an IDE based in Chrome, and we now have an isomorphic API across Client, IDE, and Testing environment. Aw yeah!

@awatson1978 commented on GitHub (Jul 6, 2015): Thanks! Glad you see the value! The Meteor API package is one of the hidden gems, and since you're clued in on this package, you're probably one of the few that will appreciate the details of the roadmap. Take a close look at the 'extract-method' package. It's ostensibly written for Ruby, but it has the complete pattern for adding menu items to Atom. The next big milestone of the 'meteor-api' package is to pretty much incorporate the entire 'extract-method' package, and adjust the three or four lines of ruby code into node/javascript. https://atom.io/packages/extract-method Then. Take a look at starrynight.meteor.com. It's the node utility I've been working on. A bit of a hodge-podge, everything-and-the-kitchen-sink sort of utility. https://github.com/awatson1978/starrynight You'll see a few interesting commands, such as: starrynight rename --from /path/to/component --to /new/path starrynight find-and-replace --from oldTerm --to newTerm These are intended to be hooked up to the Atom UI. So, StarryNight and Meteor-API are going to converge. Also. With the StarryNight utility, we've managed to swap out the Firfox browser of Nightwatch with Chrome; and the Phantom browser of TinyTest with Chrome. Add in Meteor-Api, which provides an IDE based in Chrome, and we now have an isomorphic API across Client, IDE, and Testing environment. Aw yeah!

gitea-mirror commented

2026-05-05 15:00:15 -06:00

Author

Owner

@kfalkiewicz commented on GitHub (Jul 7, 2015):

I looks primising, but syntax still isn't 100% correct. In my opinion it should look like Vanilla JS + Highlight for Meteor. Now is definitely better but not in 100%.

@kfalkiewicz commented on GitHub (Jul 7, 2015): I looks primising, but syntax still isn't 100% correct. In my opinion it should look like Vanilla JS + Highlight for Meteor. Now is definitely better but not in 100%.

gitea-mirror commented

2026-05-05 15:00:16 -06:00

Author

Owner

@awatson1978 commented on GitHub (Jul 7, 2015):

Feel free to contribute a pull request if you don't like something, instead of simply complaining. As mentioned above, the extra rules create their own complications. If you can get it to look like Vanilla JS + Highlight for Meteor, that PR will definitely go in.

@awatson1978 commented on GitHub (Jul 7, 2015): Feel free to contribute a pull request if you don't like something, instead of simply complaining. As mentioned above, the extra rules create their own complications. If you can get it to look like Vanilla JS + Highlight for Meteor, that PR will definitely go in.

Rows
Columns

[GH-ISSUE #54] Syntax highlighting on upgrade to Atom 0.200 #49