Re: Comprehensive JSX support in Emacs

[Jackson Ray Hamilton]

Hi Stefan,

Thanks for your reply and your code review.

I think it's a good idea to *default* to the sgml- settings if it's
common for users to want SGML-style indentation conventions for those
parts of the code, but if many users want to use different settings in
sgml-mode and jsx-mode, then it makes sense to offer
jsx-specific overrides.

Right.  I think Emacs’ conventions for aligning SGML attributes are mostly compatible with Reacts’, so sticking with those, it shouldn’t feel too foreign.

I think one obvious reason to have JSX-specific settings is that sgml-basic-offset defaults to 2, and js-indent-level defaults to 4; so no matter what, OOTB users probably think Emacs indents JSX “wrong.”  It would surprise me if people were actually content with using 4 spaces for JS and 2 spaces for JSX blocks within.

A philosophical and practical reason to switch will be decoupling JSX from SGML.  Using sgml-indent-line to indent JSX probably should have been kept an implementation detail, but requiring the use of sgml- variables uncovered that detail.  If I end up changing the implementation, as I’m considering, we could pay a price for that.  However, I expect that most users will have already configured their JSX indentation to be consistent with JS, and thus will be unaffected; else, I think most will welcome a change to consistent defaults as a “fix.”

Would there be any harm in activating JSX indentation&highlighting in
a _javascript_ buffer that doesn't use JSX?

Indeed, that could eliminate some false negatives and simplify the code, and we may be able to get away with it indefinitely.

However, considering _javascript_ has a well-respected specification, it seems a bit risky to me to enable non-standard syntax extensions in “.js” buffers without some precautions.  The standards body could define new syntax in the base language that invalidates userland syntax extensions, or other syntax extensions with competing semantics could become popular.  JSX itself is a successor to E4X, with which it overlaps partially.

I think long-term it’d be less disruptive to users’ configs to define parameters for enabling syntaxes that we can reasonably expect to hold up in an evolving ecosystem.  Hence, looking for specific branding—like “.jsx” files or a “React” variable—could help us to eventually gracefully add support for a “TheoreticalAngleBracketsRedux” extension also, with “.jsb” files / an “AngleBrackets” variable / a “// @Angles” magic comment to enable it…

- Any reason why you add a call to js--disambiguate-js-from-jsx at the
  end of js-syntax-propertize instead of adding it directly within the
  syntax-propertize-rules?

Reason: Me not knowing what I’m doing.  :-)  I figured that could be written better.

Actually, I was hoping we’d be able to talk about that part.  I wanted to know if you thought I should repeat the pattern that I see near that code, where js-syntax-propertize-regexp is called in syntax-propertize-function first at the beginning of the function and again later in syntax-propertize-rules — I haven’t yet figured out why that pattern of calling the same propertize function in multiple places exists in this mode and others (like ruby-mode’s ruby-syntax-propertize/ruby-syntax-propertize-heredoc).

I’ve also been wondering in the back of my mind if I’ll need to use syntax-propertize-extend-region-functions in this implementation.

Thanks again for talking this through (even though the language may feel a bit foreign!)

Jackson

(BTW, I’m currently figuring out the process for replying to a mailing list — replying to you, CCing emacs-devel, trying to set In-Reply-To in my mail client.  Hopefully that works this time.)