Closed damonmcminn closed 9 years ago
I saw this today, working with Angular. Something isn't correct here. Please fix this asap.
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.
I'm happy to take a look at this, just need a little direction in where to start looking and how to test?
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!
Is this fixed yet? It doesn't look right for me:
@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.
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.
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.
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 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?
Hi, just published version 2.20.0
. Should contain:
Superb! Love your work :)
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!
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%.
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.
Atom 0.200 default auto-detected grammar is determined by installed packages i.e. if
meteor-api
is installed, the default.js
grammar isJavaScript (Meteor)
.The syntax highlighting does not work as expected, see below.
With
JavaScript (Meteor)
:With default JavaScript grammar: