language-babel icon indicating copy to clipboard operation
language-babel copied to clipboard

Atom no longer defaulting to language-babel for .js files

Open romellogoodman opened this issue 6 years ago • 34 comments

With the latest release of the atom beta 1.32.0-beta0 language-babel no longer auto detects for .js files and instead you have to manually select it as the language

romellogoodman avatar Sep 27 '18 12:09 romellogoodman

This fixed for me, unchecking tree-sitter parsing in core settings (scroll near the end of the core settings page)

https://github.com/gandm/language-babel/issues/491

sbrichardson avatar Oct 08 '18 16:10 sbrichardson

Closing because the above fixes it for me

romellogoodman avatar Oct 24 '18 12:10 romellogoodman

That workaround isn't great - a) the package doesn't work properly with the new Atom default and b) I believe the point of tree-sitter parsers is for performance.

Can we reopen?

lexanth avatar Oct 24 '18 15:10 lexanth

Another workaround is to add this to your config:

"*":
  core:
    customFileTypes:
      "source.js.jsx": [
        "js"
      ]

However, then other packages think the file is JSX too, so something like the file-icons package shows a JSX icon next to JS files.

Why is the scope for Babel ES6 JavaScript Grammar source.js.jsx anyway? Surely it should just be source.js?

zakini avatar Oct 25 '18 11:10 zakini

Thanks

mihrich avatar Oct 26 '18 09:10 mihrich

The main issue is not with the tree-sitter, but with language-typescript package.

mgtitimoli avatar Oct 26 '18 15:10 mgtitimoli

Did disabling language-typescript solved the issue for you @mgtitimoli ? It didn't work for me, tho.

Yurickh avatar Oct 26 '18 15:10 Yurickh

It did it for me as well @Yurickh, I hope @maxbrunsfeld consider the comment I left in the issue, meanwhile there is a concensus of introducing a new flow grammar.

mgtitimoli avatar Oct 26 '18 16:10 mgtitimoli

Disabling language-typescript did not work for me.

sinwailam193 avatar Oct 26 '18 16:10 sinwailam193

Sorry to hear that @sinwailam193, in order to see what's going on in your case, could you tell us what grammar is selected?

mgtitimoli avatar Oct 26 '18 16:10 mgtitimoli

it selected language-javascript, which I understand because it is a js file. There was no issue like this before, I don't know what changed.

sinwailam193 avatar Oct 26 '18 16:10 sinwailam193

It's for the same reason I wrote before @sinwailam193, instead of disabling both language-typescript and language-javascript, do what @Zakini commented here and should set language-babel as default.

(@Yurickh I reenabled language-typescript as setting that in config worked as well)

mgtitimoli avatar Oct 26 '18 16:10 mgtitimoli

yea, @Zakini 's method worked for me, the only issue is that other plugins for some reason also think it is a jsx file. Thanks tho @mgtitimoli!

sinwailam193 avatar Oct 26 '18 16:10 sinwailam193

I believe the reason behind all this is this one, but as I wrote there if anyone can give a hint about why language-javascript and language-typescript take precedence over language-babel that would be very appreciated.

(np @sinwailam193, great that you were able to solve the issue on your side)

mgtitimoli avatar Oct 26 '18 16:10 mgtitimoli

The change is due to us enabling the new Tree-sitter parsing system by default. Sorry for the disruption, everyone. Just curious - why do folks want to use language-babel rather than the built-in parsers? Are there packages that aren't loading because they only work with the source.jsx scope, and not source.js?

maxbrunsfeld avatar Oct 26 '18 16:10 maxbrunsfeld

To me, language-babel will syntax highlight some babel-specific things, like style template tags (i.e. https://emotion.sh), which language-javascript doesn't.

EDIT: Also flow type annotations and graphql template strings.

Yurickh avatar Oct 26 '18 16:10 Yurickh

Thanks for jumping into this issue @maxbrunsfeld, language-babel IMO is currently the most complete grammar out there, it not only highlights correctly flow, but it also does the same for styled-components, graphql and obviously javascript, this is why I expressed my concern before, because a lot of people is using this setup.

mgtitimoli avatar Oct 26 '18 16:10 mgtitimoli

:+1: I see, thanks.

In case it matters to anyone, the built-in parsers now handle JSX and Flow. They do not yet handle graphql and styled components, although styled-component highlighting (via a CSS parser) is coming soon.

For other folks who are wondering, I'm going to re-post a comment I made in response to your issue on the Tree-sitter repo:


In the latest release of Atom, we've enabled our new parsing system by default, which means Atom will prefer to use the new parsers over the old TextMate grammars (which language-babel provides). To opt out of this behavior, you have a couple of options.

  1. If you want to always prefer the old-style TextMate grammars over the new parsers, you can uncheck the Use Tree-sitter Parsers checkbox in the settings view.
  2. If you just want to use language-babel for .js files, but want to use the new parsers (the default) for other languages, you can add this to your config.cson:
"*":
  core:
    customFileTypes:
      "source.js.jsx": [
        "js"
      ]

maxbrunsfeld avatar Oct 26 '18 16:10 maxbrunsfeld

I edited the code snippet in my above comment ☝️ to fix an error.

maxbrunsfeld avatar Oct 26 '18 17:10 maxbrunsfeld

So new Atom is not going to be supported? I miss GraphQL syntax.

steida avatar Oct 31 '18 18:10 steida

Built-in styled-component highlighting has shipped in Atom 1.32.1. If you are interested, please give the built-in parsing system a try and report any issues you see with highlighting embedded CSS.

I miss GraphQL syntax.

Yeah, we realize that GraphQL highlighting is very useful. We plan to eventually create a new-style Tree-sitter parser for GraphQL as well. Then, the built-in JavaScript and Flow parsing will support everything that language-babel does. Until then, if GraphQL support is important to your workflow, you can continue to use language-babel using one of the approaches in https://github.com/gandm/language-babel/issues/510#issuecomment-433466949.

maxbrunsfeld avatar Oct 31 '18 19:10 maxbrunsfeld

Just chiming in here. I don't use styled components or GraphQL and I still see a marked difference in my React components with the built-in JavaScript parser compared to language-babel.

Maybe I've just gotten used to the syntax highlighting with language-babel, but it feels like it "understands" my code much better. Notice the regex and the JSX attributes.

Built in Parser

built in js parser

language-babel

language-babel

dominic-p avatar Oct 31 '18 20:10 dominic-p

@dominic-p It looks like you're using 1.32.0; a few highlighting issues have been fixed in 1.32.1, which we published last night.

  • Component names in JSX (e.g. MessageAttachment) should now yellow again, not red.
  • { delimiters in JSX should now be dark red.

Overall, Atom is now parsing your code much, much more precisely than it ever did before. This is what allows us to provide the new syntax-aware selection feature (bound to alt-up and alt-down). As mentioned above, you can continue to use language-babel, but we really see Atom moving toward the new Tree-sitter parsing system, because of its higher accuracy, performance, and greater set of features that can be built on it, because of it providing a precise syntax tree.

Some of the changes are intentional: you should see that object properties (e.g. onMediaLoad) are colored more consistently and are differentiated from variables more clearly - previously, both variables and object properties would sometimes appear in red, and object properties would also sometimes appear green.

Other changes are not necessarily intentional. For example, it looks like we're using a different color for character classes in regexes than language-babel does. We only use that orange color for escape sequences in regexes (e.g. \n). For me, neither one is clearly better, but I could be convinced otherwise. If you have any specific issues with the syntax highlighting after upgrading to Atom 1.32.1, please open issues on atom/language-javascript.

Thanks for chiming in with those screenshots!

maxbrunsfeld avatar Oct 31 '18 21:10 maxbrunsfeld

@maxbrunsfeld It would be great to have colored function parameters, currently they are white which kinda stands out from the rest and feels strange after using babel coloring. Same goes to variable declarations.

vladshcherbin avatar Oct 31 '18 21:10 vladshcherbin

Thanks for the detailed feedback @maxbrunsfeld I appreciate it. Most of my reaction is probably due to the fact that I have gotten so used to the language-babel syntax highlighting. It's hard to say objectively, for instance, whether the more liberal use of bright yellow in the new parser is better than the dark red in language-babel.

I would echo @vladshcherbin on the white color. I understand from your previous comment that the change was intentional, but to me white kind of feels like the parser wasn't able to figure out what something was. Again, this is probably mostly personal preference.

The only other comment I would make on the regex is that I see a lot more detail in the language-babel coloring. With the built in parser, it seems to be saying: "this is a regular expression". The language-babel parser is telling me: "this is a regular expression, it has a flag modifier and a negated character class". It helps me understand what a regex is doing much faster.

I probably should have posted all of this on the language-javascript repo you linked...sorry about that.

dominic-p avatar Oct 31 '18 22:10 dominic-p

I've been using language-javascript for the last couple days, and one feature I've been missing is the auto {/* */} comments instead of the classical // comments, when inside JSX. I'm not sure where I could check/contribute to.

Is this responsibility of the language-javascript repo as well?

Yurickh avatar Nov 01 '18 18:11 Yurickh

I've been using language-javascript for the last couple days, and one feature I've been missing is the auto {/* */} comments instead of the classical // comments, when inside JSX. I'm not sure where I could check/contribute to.

This and autocompleted tag closure is a time (and sanity) saver for me. It seems like these features could be separated from the syntax highlighting though?

SpainTrain avatar Nov 01 '18 23:11 SpainTrain

I have custom styles that highlighted all function names in a light green so they're easily noticeable. These are now broken for arrow functions and anonymous functions that are assigned to a variable, because variable names have no tag or style. They're just text nodes and so cannot be targeted with css. Is this something that could be fixed?

If you're interested, my custom styles look like the below. The top one is for functions and the other for arrow functions.

@function-color: lightgreen;

.syntax--storage.syntax--type.syntax--function + .syntax--entity.syntax--name.syntax--function {
  color: @function-color;
}

.syntax--meta.syntax--function.syntax--arrow > .syntax--entity.syntax--name.syntax--function {
  color: @function-color;
}

VarunBalakrishna avatar Nov 07 '18 05:11 VarunBalakrishna

There are three elements of the language-babel syntax highlighting in JS/JSX I like that the built in language-javascript doesn't do:

  1. Components have a separate color and really stand out
  2. html properties go to italic which makes them really easy to parse
  3. In language-javascript, variables and control operators are nearly the same color (very light gray vs white respectively). In language-babel, the variables and control operators really contrast each other for better readability.

Compare the following.

language-javascript

javascript

language-babel

babel

chucksense avatar Nov 30 '18 19:11 chucksense

Disabling Use Tree Sitter Parser only fixes the autocompletion of tags, but does not fix the commenting with {/* */}, this means I have to manually type that around my tags in order to render properly. Is there any known fixes for the commenting issue?

I changed my theme and now the commenting works, I guess it's a theme styling issue as well??

CragVFX avatar Dec 12 '18 16:12 CragVFX