bug#24896: JSX prop indentation after fat arrow

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.01.2017 20:44, Felipe Ochoa wrote:
> So I've thought about this some more, and realized that this won't fix
> everything. There are still issues with greater-than and less-than as
> binary operators.

Inside XML literals, you mean?

> Maybe a better idea is to give '{' and '}' comment
> syntax ('<' and '>') so that SGML ignores all the bracketed JS stuff.
> I've been trialing this with the following:

How's your experience so far?

> (defvar js-jsx-tag-syntax-table
>   (let ((table (make-syntax-table sgml-tag-syntax-table)))
>     (modify-syntax-entry ?\{ "<" table)
>     (modify-syntax-entry ?\} ">" table)
>     table))
>
> (defun advice-js-jsx-indent-line (orig-fun)
>   (interactive)
>   (let ((sgml-tag-syntax-table js-jsx-tag-syntax-table))
>     (apply orig-fun nil)))

Here's the problem: js-indent-line uses syntax-ppss. sgml-indent-line 
doesn't (for now), but js-jsx-indent-line calls js-indent-line in 
certain contexts.

And this is a problem because calling syntax-ppss in different contexts 
with incompatible (paren-wise) syntax tables will make syntax-ppss cache 
broken, and lead to likewise broken behaviors.

So, one thing we could do here is let-bind the variables that constitute 
syntax-ppss cache around the call to orig-fun (i.e. around the context 
where we modify the syntax table).

Another, somewhat more difficult approach, would be to try to apply the 
"<" and ">" syntax classes in syntax-propertize-function, only to 
occurrences of "{" and "}" inside XML literals.

That would require knowing where the said literals begin and end, but we 
do know that somehow already, seeing as we know which indentation 
function to choose, right?

This way we don't depend on syntax-ppss internals (the cache is not 
really a public API), and reindenting the whole buffer might be faster, 
because we would keep syntax-ppss cache around more. Still, not sure how 
much faster that would be in practice.