Re: Comprehensive JSX support in Emacs

[Dmitry Gutov]

On 06.04.2019 18:55, Jackson Ray Hamilton wrote:

> > It's probably still worth it to get the feature into master soon.
> I agree.  I’ll see if I can tackle the performance issue first, then 
> I’ll rebase/merge the branch into master.

It might be worth it to merge even if the issue turns out to be too 
difficult to deal with right away, though.

> > Do you have commit access?
> I’m not sure.  If not, will someone please grant it to me?

You'll need to register at https://savannah.gnu.org/, find the 'emacs' 
group and request access there (there's a button).

> > The colors are very nice to have. Do you think this approach is 
> > portable to js2-mode?
> Possibly…  js-mode is using font-lock keywords to add the colors, but 
> js2-mode apparently isn’t.  js2-mode would need to pay attention to the 
> js-jsx-* text properties like in js-jsx--font-lock-keywords and apply 
> colors like in the associated matcher functions (js-jsx--match-tag-name, 
> js-jsx--match-attribute-name, et al).

*shrug*, font-lock-keywords also usually work there (e.g. when added 
from a hook or a minor mode), so maybe the easiest approach would work too.

> Until someone steps up to add proper JSX parsing to the JS2 AST… perhaps 
> a fusion of the keywords-style and AST-style colorings could provide JSX 
> and JS coloring (respectively) in JS2.

Yup.

> I’ll check for that.  I’m also planning on analyzing the results of 
> elp-instrument-package and doing some step-debugging to deduce where and 
> why it’s lagging.
>
> I’ve already found that it’s lagging when I’m editing a large chunk of 
> JSX code or the code before it.  However, if I edit code in the buffer 
> following the chunk of JSX, then the lag noticeably drops.  You can see 
> this by opening the attached “Slow JSX.jsx” file and editing it.  This 
> might be related to how I extended syntax propertization and 
> font-locking to the boundaries of a root enclosing JSXElement; if a root 
> is hundreds of lines long, there could be negative consequences.  Maybe 
> we can be more conservative with the parsing/coloring, somehow.

I'll leave that investigation to you and Stefan, for now at least.

Thanks for working on it.