JSX support breaks in v2.1.4

[a-y-u-s-h]

After adding:

{
    "keys": ["ctrl+e"],
    "command": "emmet_expand_abbreviation"
}

• Emmet doesn't expand JSX if it's not written w/ JSX document syntax - undesirable, because syntax highlighters for JSX syntax aren't feature-rich, whereas others are (Javascript, Typescript) so it should support them all.
• Emmet expands h1.name to <h1 class="name"></h1> inside JSX - undesirable because it's still behaving like HTML expansions.

Would be awesome if somehow reverting to older version works or maybe a newer update is published with older code (since too many people will face issues with so many things breaking).

[sergeche]

Did you tried to start abbreviation with < and use Tab to expand it?

[a-y-u-s-h]

@sergeche More info: I've tried it in both function and class components. With and without parent, and with shorter syntax of React Fragments <></> as parent.

Do you mean with: <h1.name ? That expands to: <<h1 class="name"></h1>

[sergeche]

Which syntax do you use for JSX?

[a-y-u-s-h]

The one in top 100: https://packagecontrol.io/packages/JSX

[sergeche]

Do you mean with: <h1.name ?

I mean this: https://github.com/emmetio/sublime-text-plugin#jsx-support

Check out v2.1.6, it might fix this issue with JS syntax. It looks like you’re using some JS syntax for JSX highlighting.

[a-y-u-s-h]

@sergeche Will check it out, can't see v2.1.6 on Command Pallette search yet. Though yes, I'm getting the same problem in v2.1.4 w/ this as well.

[sergeche]

Try to restart editor, package might be updated automatically

[a-y-u-s-h]

Just updated to v2.1.7 - same issue.

[joeyparis]

I also updated to v2.1.7 this morning and have the same issue

[sergeche]

Please describe precisely what you do and what abbreviation you type. What syntax do you set, sample files etc.
Also, a short video with process would help.

And check ST console if there are any errors

[asumaran]

My Emmet Plugin got updated today and I'm also noticing some weird behavior.

Usually I was able to expand with Tab but now nothing happens a tab space is added instead. The expansion seems to work if I press ctrl + space though.

I had this keybinding set up before but now it's not working with or without the keybinding added.

keybinding

{
"keys": ["tab"],
"command": "expand_abbreviation_by_tab",

// put comma-separated syntax selectors for which
// you want to expandEmmet abbreviations into "operand" key
// instead of SCOPE_SELECTOR.
// Examples: source.js, text.html - source
"context": [{
"operand": "meta.group.braces.round.js, text.html, source.tsx",
"operator": "equal",
"match_all": true,
"key": "selector"
},

// run only if there's no selected text
{
  "match_all": true,
  "key": "selection_empty"
},

// don't work if there are active tabstops
{
  "operator": "equal",
  "operand": false,
  "match_all": true,
  "key": "has_next_field"
},

// don't work if completion popup is visible and you
// want to insert completion with Tab. If you want to
// expand Emmet with Tab even if popup is visible -- 
// remove this section
{
  "operand": false,
  "operator": "equal",
  "match_all": true,
  "key": "auto_complete_visible"
},
{
  "match_all": true,
  "key": "is_abbreviation"
}

]
}

[sergeche]

@asumaran you should prefix JSX abbreviations with <: https://github.com/emmetio/sublime-text-plugin#jsx-support

And you should remove this keybinding, it’s no longer valid

[asumaran]

@sergeche Thanks! It seems to be working fine the way it says in the Readme. I'll remove the keybinding.

[a-y-u-s-h]

@sergeche It suddenly works now today. I haven't updated Emmet v2.1.7 today and yet typing h1.name and expanding works with and without prefix and with Javascript and Javascript (Babel) syntax definitions.

[sergeche]

I guess there was some kind of invalid update. I’ve released a few versions more recently, might be automagically fixed

[h0jeZvgoxFepBQ2C]

Oh damn, is it not possible anymore to just start with a dot and press tab and get a div with className? How can I restore this behaviour?

[sergeche]

@h0jeZvgoxFepBQ2C works for me. Make sure you set document syntax to HTML

[h0jeZvgoxFepBQ2C]

In a JSX File?

[sergeche]

In JSX, it’s <.

[h0jeZvgoxFepBQ2C]

Yeah, but my question was how I can restore the old behaviour? Before the update it worked without writing <?

[sergeche]

If you don’t want to use native ST snippets in JSX, you can mimic old behaviour

[h0jeZvgoxFepBQ2C]

Thanks, I really prefer the old way more :)

[a-y-u-s-h]

@sergeche Doing what you suggested above overrides the snippets outside of markup in Javascript/JSX files as well.

import React from "react"

fun<tab> // Exapands to <fun></fun> here.

export default () => {

  return <>
fun<tab> // Also expands to <fun></fun> here.
</>
}

Desired:

import React from "react"

fun<tab> // Should expand to 

function  () {
  
}

// Also emmet autocomplete shouldn't be present here.

export default () => {

  return <>
fun<tab> // Also expands to <fun></fun> here.
</>
}

I googled a bit and tried changing some scope to meta.group.braces.round.js, text.html...no luck.

[sergeche]

@a-y-u-s-h that’s the reason why Emmet v2 required < prefix for JSX abbreviations: there’s no sane way to properly detect what should actually happen after you hit Tab after fun

[a-y-u-s-h]

@sergeche Could difference of scopes be one or are there any edge cases in this as well?: scopes on both of those places are different. Hitting Ctrl + Alt + Shift + P gives me scope of source.js meta.import.js (meta.import.js if there's a function between import statements and default export component, otherwise source.js) and full scope of content between JSX tags is: source.js meta.function.js meta.block.js meta.group.js meta.jsx.js.

[sergeche]

@a-y-u-s-h there’s lots of edge cases here. For example, you can’t have proper scope for cases like this:

const elem = div| // Tab should convert to <div>

[a-y-u-s-h]

I see. Yeah you're right. But I think keeping the parens scope (or the longer one with meta.jsx.js and scope within class syntax and function syntax) would be a better developer experience than doing < every time. But either way, Ctrl + E works good too, a bit limited but it's predictable and feels like it's less strokes. Easier than prefixing with < and then hitting tab. May be a personal preference but I feel there might be a good demand for similar behavior with tab like in usual HTML, ignoring some rare use-cases. Hard to identify what classifies as 'rare' though.

In my experience, this actually a very rare usecase (though I completely get it that this is a valid edge case):

const elem = div|  

I think this is much more common (and it has almost same scope) in:

const elem = props => div|

And these are just function components. Usually you always return JSX instead of assigning it to a variable. I'm a sucker for generalization as well. And I won't insist on it, but will let you decide if you think it's easy to implement TAB trigger to consider a large group of common usecases which can be differentiated with scopes, compared to compulsory < prefix, because in my opinion it sort of ruins the experience in other very common use-cases as well (and messes up snippets on the non-function scope). I have to disable it to use any other JS snippet.

[sergeche]

Added jsx_prefix Emmet setting to enable/disable JSX prefixes in v2.2.2