Re: Comprehensive JSX support in Emacs

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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.

Makes sense.

> 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.”

I think such breakage is usually not a big deal, as long as there's
a clear explanation somewhere of why it's changed and how to get back
the old behavior.

>> 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.

BTW, I do think it's important to keep this feature conditional on some
setting, but if it's mostly harmless, then we can be a lot more lazy (in
the sense of a lazy programmer, not a lazy program) in terms of when we
enable/disable 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.

OK, good.

> 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).

This pattern is used to deal with "modes".  `syntax-propertize-rules`
doesn't try to find matched to all the regexps everywhere: once a regexp
has matched its code is run and that code can move point and after that
we start matching again at that position.  This is typically used for
things that are "string-like" or "comment-like" so we don't mistakenly
treat the inside of one of those elements (which typically contains
arbitrary text rather than code) as code, and so we correctly recognize
and mark the "end".

The pattern you mention happens for those kinds of situations, in order
to handle the case where syntax-propertize-function is called with point
in the middle of one of those "string/comment-like" elements.

> 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.

If your code which propertizes the < and > also wants to skip text and
prevent the rest of the syntax-propertize-rules to apply to that skipped
text, then you'll probably want to follow that same pattern.  But if
not, then it's not needed.


        Stefan


> (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.)

I just "reply-all".